dvfs api and toolkits
jamiemcc at blueyonder.co.uk
Tue Apr 5 01:48:15 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.
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.
More information about the xdg