dvfs api and toolkits
nf2 at scheinwelt.at
Tue Apr 5 01:10:37 EEST 2005
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
More information about the xdg