A common VFS and a Common conf-system [Part II]

[nf2]

Waldo Bastian wrote:

>On Tuesday 01 March 2005 16:48, Sean Middleditch wrote:
>  
>
>>My original idea was to *NOT* have the backends run in the library or
>>host app itself, but instead to have a per-user daemon that handled all
>>of the actual VFS work, and then the library would simply be an API that
>>made it easy for an app to talk to the daemon.
>>    
>>
>
>Yes, I think this is a good approach. We may want to put some thought in 
>whether we would want to have a single-threaded daemon process, a 
>multi-threaded daemon or a single process deamon with additional worker 
>processes.
>
>  
>
I think there are only two options:

1) A single multithreaded daemon with threads per VFS connection (like 
Gnome-VFS daemon modules). The problem with this is that a buggy VFS 
module could crash the whole VFS system.

2) Separate multithreaded daemons for every VFS "session" (like a ftp 
user at server combination). Like in the first case every connection would 
have it's own thread in the session daemon.
Session data like passwords would then be kept in the "session" daemon 
process.
This would require a "registry" daemon to manage the session daemons.

IMO having single threaded "per connection" processes like KIO is 
problematic from design, because it makes access synchronization very hard:

Some VFS resources will need access synchronization - editing archives 
for instance - or a FTP server which permits only one connection per 
user. In this case a "pausing - have to finish another operation" 
callback would be nice feedback.


Concering the internal interface for VFS-Modules i would go the 
synchronous Gnome-VFS direction with open-read/write-close methods plus 
callbacks. VFS modules should be as portable and universal as possible 
(like linking them into servers or CLI tools directly without making use 
of the Desktop-VFS framework).

But the interface should be "weak typed": Data structures for 
"queryInterface()", Directory-Entries and Callbacks should be a bit like 
PHP arrays (key-value maps which can also be hierarchical).

This "weak typing" would make it possible to use the same 
open/read/write methods to access directories and files (Don't know if 
that makes sense). The VFS library could even be used to access the 
desktop configuration database - it would be just another VFS module. 
Perhaps one should see the Desktop-VFS as an "application server".

For the async frontend i would steal many ideas from KIO. Cause it's 
very friendly to application developers and the "home grown" IPC 
protocol seems to be quite lean.

regards,
Norbert