VIO - Visual IO Agents

[nf2]

Lennon Cook wrote:
> nf2 <nf2 at scheinwelt.at> 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.