Lennon Cook wrote:
nf2 <[EMAIL PROTECTED]> wrote:
The second part of the problem - i think - is the lack of
user-interface and "controlability" in an completely transparent vfs.
There is no smart way of knowing for how long an FTP server should
stay connected. It's also impossible to say when an archive that has
been opened for writing should be repacked and stored.
Easy. Mimic the lower level, and keep reference counts. Allow the
archives and the ftp:// URIs to be passed to something mimicking
open(3p)/opendir(3p), do everything necessary to make them available,
increment the refcount. Decrement it on calls mimicking
close(3p)/closedir(3p), or on noticing that a client app dies.
The problem is that you also have to keep the connection open for a
while even if there are no active operations. Otherwise you have to
reconnect many times when the user walks through the hierarchy of an
FTP-server with his filemanager, or -dialog for instance - which will be
very slow...
Or do you mean the application should keep an explicit reference as long
as it is working with a certain file/directory. This reminds me of the
"umount - device is busy" nightmare... The archive might not be stored
forever, because someone forgot to release a reference. But -
nevertheless - to have some kind of way to find out who's using a
resource wouldn't be a bad thing :-)
Having GUIs at something this low-level is probably a bad idea. For
one, you risk designing an interface that isn't sane everywhere
(choices of toolkit and HIG, for example), which can't claim to be any
more desktop neutral than what we have now. And why shouldn't the
CLI users benefit from this? Just because we might think they're insane
isn't a reason to ignore them, or there wouldn't be KDE and Gnome
people on this list talking to each other.
You could lauch KFTPAgent, GFTPAgent, CLIFTPAgent... - whichever you
prefer...
n.
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
