[Portland] Transport mechanism

[Lubos Lunak]

 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.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/