D-BUS spec - comments on wire protocol

[Sean Middleditch]

On Sat, 2005-01-22 at 13:24 +0000, Robert Wittams wrote:
> > 
> > To me a better approach than allowing huge arrays would be some kind of
> > standard support for streams.
> > 
> 
> I've been wondering about this. One of the nicest features in modern 
> unices is being able to pass file descriptors over unix domain sockets. 
> Its the closest thing to capabilities we have in unix land. (Real 
> capabilities, not Posix ones).

Although, iirc, it isn't supported on all UNIXes, and D-BUS is intended
to be very portable.  Darwin in particular.  Not sure on that, thought.
(Darwin's severely limited functionality has bitten me in other places,
so maybe I'm just bitter.  ~_^ )

> 
> It would be a shame if D-Bus precluded the use of these. If some 
> standardized support for streams were included, would it be possible to 
> have them implemented as fd passing on the unix domain socket transport?

There are problems with that approach.  Say I want to stream X bytes
from a file over D-BUS.  If I just pass the descriptor then the
receiving app can do a lot of things I don't want it to; it could read
more than X bytes, for example, which could potentially be a security
breach.

> 
> Doing remote (TCP) ones would be harder ( if you want to preserve the 
> capability-ness of them), but I think it is possible. The E language for 
> example supports this kind of thing IIRC.

Possible, yes, but grotesquely complicated.  That is a level of over-
engineering that D-BUS specifically tries to avoid.  If you really need
that kind of behaviour then don't use D-BUS - that's not what it's
primarily designed for.

> 
> It could also prove a performance win for things like Sean Middleditch's 
> proposed VFS over Dbus. eg for some protocols it might be possible to 
> pass off the socket after parsing the header...

Actually, that wouldn't be allowed in the VFS, due to connection
sharing.  Also, I doubt there'd be any performance gain noticeable - the
cost incurred by transferring packets of data between the VFS daemon and
the application would usually be dwarfed by the latency in the actual
network connection to the remote server.

If it *does* become a problem, I'd much much rather keep everything 100%
abstracted behind the VFS API, since then D-BUS could just be replaced
with a home-grown solution that's better optimized for our needs.

Well designed, future-proof APIs are our friends. ~_^

> 
> Any of this make sense?
> 
> Rob
>