dvfs api and toolkits

[nf2]

Sean Middleditch wrote:

>On Mon, 2005-04-04 at 22:18 +0100, Jamie McCracken wrote:
>  
>
>>Sean Middleditch wrote: 
>>    
>>
>>>D-VFS will provide A.  You can wrap both B and C around A, so there's no
>>>good reason to bloat the D-VFS protocol or daemon with special support
>>>for either B or C.
>>>      
>>>
>>Given that the backend drivers will either be A or C wouldn't it make 
>>more sense to support both in the daemon? (it just sounds terribly 
>>inefficient to convert a "C" driver to an "A" in the daemon and then 
>>back to "C" in the client toolkit!)
>>    
>>
>
>No.  It would make the daemon considerably more complex to provide a
>synchronous mode of operation, especially since all backends *must not*
>be synchronous.  All backends will work using an asynchronous mode, that
>will be expressed in the over-the-wire interface with the daemon, and
>wrapping that interface into a synchronous mode will *not* cause any
>significant loss of efficiency.
>  
>
I doubt that async (A) mode in the daemon would work. It would cause too 
many problems regarding flow control ("traffic congestion")... How do 
you want to deal with messages from a backend when a client is busy and 
doesn't read from its socket (or the other way round). Buffer them? For 
how long? Or use something crazy like the "alternating bitburger" 
protocol (Used in KIO for copying files)?

I'd bet (a bottle of bitburger) that the daemon will be designed in 
synchronous (C) style using threads. You can't compare a VFS daemon with 
a Web-Server. A VFS backend has two "pipes" to talk to - the client and 
the outside world - with different speeds - which makes async design 
very hard.

Norbert