VIO - Visual IO Agents

[nf2]

Brian J. Tarricone wrote:
> nf2 wrote:
>   
>> Donald Straney wrote:
>> I think a GUI for handlers would definitely help the user. For instance
>> i do a lot of PHP programming directly on the webserver. For editing i
>> use JEdit (because it works transparently over FTP). For copying files i
>> use Nautilus. The problem is that it's intransparent when my desktop is
>> connected to the FTP server. So i get annoying connection errors,
>> because the FTP-server only allowes a certain number of concurrent
>> connections. If the protocol handler had a GUI i could monitor
>> connections and disconnect with a mouseclick.
>>     
>
> That sounds like an "unbreak my software" GUI.  The real solution is to
> fix the VFS layer to be better about a) caching and reusing connections
> so as not to create an unnecessary number of them, b) handling errors
> like that internally without bothering the user by disconnecting unused
> connections or reusing an existing one, and c) being smarter about
> knowing when a connection is really not being used and disconnecting it.
>   
Of course it should do that. Thats why the protocol handlers should run 
as one (multithreaded) instance per vfs resource: To be able to handle 
smart connection management for multiple clients. But that's only one 
part of the problem. 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.
> I have to say I agree with the other posters: most of this belongs much
> lower than user application level.
>   
Yes - and no. It's true that the interface to the vfs system should be 
below the application and desktop layer (and not inside desktops like 
now). That's the idea behind libvio. Everything vfs related should go 
through the same low-level interface. But that doesn't mean that 
protocol-handlers have to be gui-less.

Perhaps it is misleading to call them applications, but they could be 
"almost" like applications: Launchable executables which bring their own 
gui. With the limitation that you can only launch one of them at a time 
for a certain resource (user at server) - and with support for auto-launching.

This is a bit unorthodox, but it would give protocol-handlers complete 
freedom about the toolkit they use, the language they are written in, 
how they interact with the user and it would make them desktop 
independent regarding where and how they store their configuration, 
passwords,...

It seems that users find it easy to understand the model of "old 
fashioned" applications like gftp, winscp, file-roller: It supports the 
kind of modular thinking users have about their computer: "i install and 
run a certain gui-application for a certain task - and i close it when 
i'm done." Furthermore those applications have a rich gui, give lots of 
feedback, they allow monitoring activity etc...

I think it would be interesting to be able to combine this (successfull) 
model with the ambition of KIO/Gnome-VFS to give all applications and 
filemanagers on a desktop direct access to network resources, 
archives,... :-)

norbert