[Portland] Transport mechanism

[Alex Graveley]

Hi,

I haven't been following this very closely, but really please consider 
using D-BUS.  IPC is not easy to make stable, efficient, or fault 
tolerant.  This daemon is going to have to be rock solid if it's going 
to handle the requests of real life 3rd party applications.  D-BUS has 
had a lot of this work put into it, and has been accepted as the right 
way forward for both GNOME and KDE.

I wonder if you will receive a enough traction from the distros, some of 
whom heavy backed D-BUS development, by inventing your own hand-rolled IPC.

Obviously, you are doing all the work, so it's your call.

-Alex

Lubos Lunak wrote:
>  How to handle the talking between clients and the dameon. There are basically 
> these issues:
> 
> - Localhost vs supporting one app on a different host: The sensible solution 
> right now seems to be ignoring anything that's not on the same host like the 
> daemon. Libraries actually work the same way, and remote hosts are going to 
> cause their own bunch of problems (local files are not local anymore, etc.). 
> Note that this doesn't include desktops running on remote X, but only apps 
> running on a different host than the desktop. Which should be so relatively 
> rare case that just ignoring it for now should be fine. If later deemed 
> useful it could be handled by another proxy daemon that'd somehow handle the 
> remote problems or we could redesign some things. I don't think we need these 
> trouble now.
> 
> - Running an app as a different user then the desktop: This is probably a 
> variantion of the above case. Local things then will be local but may not be 
> accessible. The simple "solution" seems to be the same.
> 
> - Sockets vs something like DBUS: If we restrict ourselves to localhost and 
> one user, many things become pretty simple. No need to authenticate, no need 
> to do real marshalling as something like memcpy( buf, &foo, sizeof( foo )) 
> often does the job, roundtrip costs are not significant (although things like 
> doing a roundtrip per reading one config value should be still avoided), 
> reading can be considered not to block. In short, simple transport for now 
> should do as "simple" is probably what we now need. DBUS can be a better 
> option for the future, but right now I think we should now go with local 
> socket. If nothing else, DBUS is still AFAIK considered unstable. 
> Autogenerating the code and C API should largely shield from possible changes 
> in this area.
> 
> - Wire format: As already said above, it can be pretty simple. Message can be 
> { int id; int seq; int length; char rest[ length ]; }. The actual body can be 
> mostly marshalled as memcpy( buf, &foo, sizeof( foo )), variable length stuff 
> like strings can be again { int length; char data[ length ]; }, arrays 
> similarly, maps can be { int count; X key1, Y value1, X key2, Y 
> value2, .... }. String encoding utf8.
> 
>  The int seq is there to handle parallel operations, e.g. for two download 
> operations one needs to be able to tell which of the operations actually 
> finished.
>