dvfs api and toolkits

[Jamie McCracken]

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.

Well it is more threads for sync drivers but okay it might be a 
realtively small hit.

> 
> In fact, it should be no less efficient than the basic wrapper around
> the IPC mechanism itself, which is something you absolutely must have no
> matter what in order to ensure correct processing of the protocol.
> 

That would depend on whether the wrapper allowed direct access to the 
backend (ie in process usage). Obviously to do this you would need to be 
able to query the backend (is it A or C and whether it needs the daemon 
for connection/password) - being able to bypass the daemon if its not 
required is certainly possible but I dont know whether you plan to allow 
for that on the client side. I do feel its necessary as there's bound to 
be performance critical apps that would want this and if thats the case 
they can do their own threading if necessary.

I also feel more direct access to the drivers would provide more 
primitive posix style operations (read/write x bytes) and thus provide 
more flexibility then the high level document interface which might not 
be appropriate for some things (EG log files where you want to append 
text without reading the whole file into memory, mime type sniffing 
using the first 100 bytes of a file etc)

It could be that you have two objects on the client side - one for low 
level access sans daemon and the other for providing a high level 
document interface which always utilises the daemon.

jamie.