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

[Jamie McCracken]

Sean Middleditch wrote:
> On Wed, 2005-03-02 at 23:39 +0100, nf2 wrote:
> 
>>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.
> 
> 
> Why would the daemon even need to be threaded at all?  What advantages
> in *concrete* terms do you hope to solve with a threaded daemon that
> couldn't be done just a well with a single-threaded daemon?


If its single threaded then it must be 100% async (otherwise waiting for 
a slow FTP connection would block other apps trying to access local 
storage).

An async one would also probably be unfreindly like the current 
Gnome-vfs thats why I say go for the in process route - we dont need 
threads or unfriendly async calls everywhere (well we will still need a 
few of them I suppose so apps dont appear dead while waiting!)

jamie.