This depends only on the application. If the application first "downloads" the file and then starts working, the ioslave can't do anything about it. 
Using a KIO::get() job the apps would be able to work with the data as soon as the bytes are received.
Maybe better file a bug report to the applications which show this behaviour.

Bye
Alex

Just thought I'd post my reply from debian-kde@lists.debian.org for the sake of noting my oppinion about this.

On Saturday 10 January 2004 07:11, Amit Shah wrote:
> This depends only on the application. If the application first "downloads"
> the file and then starts working, the ioslave can't do anything about it.
> Using a KIO::get() job the apps would be able to work with the data as soon
> as the bytes are received.
> Maybe better file a bug report to the applications which show this
> behaviour.

I think you probably should have filed it against KIO itself, and not against 
smb specifically, since the smb ioslave can't really do anything about this. 
It can only work under the rules of the system which is KIO.

It's true that you can get chunks of data with KIO::get(), but you have no 
control over how large those chunks are, so all you can do is store 
everything in a temporary file and hope you get enough to work with.

I am not completely sure, but I do believe a good deal of multimedia formats 
require you to be able to scan to the end, to check file length or get 
metadata. This wouldn't work for those kind of files. Also there is still the 
problem of fast forwarding and rewinding.

There is also the problem that a lot of software like xine and mplayer has 
absolutely no knowledge of kdes native ioslaves, and has a hardwired 
requirement, that stuff is mounted locally for it to be able to play it. The 
only exception to this is streamed data like internet radio, which the 
application handles in its own way. In a way you could say it implements it 
own kind of ioslave to handle those kinds of streams, but they have nothing 
to do with the kde ioslaves.

It is possible that you could make plugins at least for xine, which would make 
it ioslave aware, but still you would need to cache almost everything 
locally, which eventually means you need to copy the entire file. So in a way 
we have gotten nowhere

Maybe you are beginning to see that this is not a simple problem which can be 
fixes just by the snapping of fingers. Actually you have no idea what a worms 
nest you are digging yourself into here. There has been a design decision 
early on that scanning in files wasn't a priority for ioslaves. In a way this 
makes sence because not all the protocols that ioslaves support has a 
sensible scanning implementation. It simply doesn't make sence to scan around 
in data you are recieving via http for example. Http wasn't designed for 
this.

There is a fundamental schism between whats in the file system and what the 
user interface tries to make you believe is the file system. The kind of 
functionality you want is only awailable in the real filesystem, not the 
pretend one that ioslaves supplies.

In the end it all boils down to security issues. Because linux doesn't let you 
mount just anything anywhere because this would be a security risk, you have 
to mess around with config files if you want to be able to mount for instance 
the smbfs in a user directory, and then you don't get the benefits of share 
browsing, since smbfs only supports mounting a share which you know is there.

A vast improvement on this in my humble oppinion would be if share browsing 
was part of smbfs. That way you could just mount smbfs during boot, and have 
it autocreate a directory when a new host becomes available, create 
subdirectories for the shares on the host, and have the contents of the 
shares automounted in these directories. This would be a real sollution.

So you see that, your simple innocent problem of not having to copy the entire 
file when you want to watch a movie, which is entirely sensible, actually 
contains a nightmare of a problem which has roots running all the way down to 
how linux is designed.

What can you do?

Well right now I would recommend doing what I do, which is to mount the 
individual shares locally using smbfs. For this you need either smbfs 
compiled into the kernel (that's what I do) or load the smb kernel module.
You also need the smbfs debian package which has the scripts and tools needed 
to mount the filesystem.
When you have that ready you can start mounting the filesystem anywhere as 
root with the command:

# mount -t smbfs //host/share /path/in/your/local/filesystem

When you get tired of having to be root every time you want to mount 
something, you can start messing with the fstabs. That is in /etc/fstab you 
can add entries like (in one line:

//host/share /path/in/filesystem smbfs rw,user,noauto,fmask=777,dmask=777 0 0

This makes it possible to mount the share as user with the simple command:

> mount //host/share

Still I don't think this is satisfactory at all, and I'll bet you don't think 
so either.

So what can you do? Well you can code it yourself obviously. I'll probably do 
this one day, when this has finally driven me insane.

Kind Regards

Anders E. Andersen