dvfs api and toolkits

[Sean Middleditch]

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.

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.

There's nothing to be gained by making the server or protocol have
special support for synchronous operation, nothing at all.  You'd just
end up with two sets of protocol definitions and daemon APIs to do the
exact same thing with pretty much the exact same overhead and
client-side behavior.

-- 
Sean Middleditch <elanthis at awesomeplay.com>