[Portland] Transport mechanism

[Lubos Lunak]

On Friday 03 March 2006 08:14, Dan Kegel wrote:
> On 3/2/06, Alex Graveley <alex at beatniksoftware.com> wrote:
> > Lubos Lunak wrote:
> > > If nothing else, DBUS is still AFAIK considered unstable.
> >
> > I haven't been following this very closely, but really please consider
> > using D-BUS.

 I (we) have.

> > IPC is not easy to make stable, efficient, or fault tolerant.

 That depends on the requirements. Requirements in this case are rather low.

> > 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.

 s/right way/only way/ - if you think that KDE developers woke up one day and 
said "oh, here comes DBUS, that's great, let's switch", then you're very very 
mistaken.

> > 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. 

 That's actually irrelevant (and IMHO it'd be hardly a reason anyway, at least 
for distros that generally decide based on what works). The only ones that 
matter here are ISVs that'd be using it. Even when considering the really 
far-fetched case of a single developer creating the client library and 
daemons for all desktops[*], then if ISVs (apps in general) start using it, 
it'll be used. If apps don't use it, it's dead, regardless of everything 
else.

[*] No, I don't volunteer, that's just an example.

> Indeed.
> Lubos, can you point to the instability of D-BUS you were
> referring to?

 http://www.freedesktop.org/wiki/Software/dbus:
"The D-BUS API isn't finished yet, and the design is by no means set in 
stone."

> Before we go off way off defining our own protocol, let's try
> just using D-BUS.  It has its own marshalling and everything,
> even if it is (yuck!) xml inside.

 Sure, go ahead. (And even though this may look like sarcasm, it's not.)


 Look, seriously, it's roughly like this: Before I created my code this list 
had been dead for more than a month, and even before that it had seen only 
theoretical discussions (well, and an "intervention" from Linus). I didn't 
want this idea to die and I didn't see it getting anywhere with, so I quickly 
created something that'd resurrect this and get it moving again. The only two 
IPCs I know are sockets and DCOP, so I didn't need to think twice, for a 
couple of reasons. And it actually seemed to me like sockets would have some 
advantages.

Sockets:
+ pretty simple - I can add marshalling to a buffer instead of writing 
directly to sockets and the transport layer is stable, efficient and fault 
tolerant. A little more work on dispatching the calls and the API is ready as 
well.
+ no extra dependencies
- problems with different hosts - note that right now I completely ignore this 
problem for more than just this reason
- problems with apps running under different users in the same desktop

DBUS:
+ it's tested (not sure if that extensively, but definitely better)
+ it should be a ready IPC (when it's considered ready, not sure that's now)
- it's complex and contains a lot of stuff that's not needed
- it's officially not stable
- there's nobody here currently working on this

 Note that as I've said already several times I know only little about DBUS. 
If some of the things above are not true, feel free to fix them. So if 
there's somebody going to make it DBUS-based, just go ahead, there's plenty 
of room in the CVS, as soon as it's obvious what to choose, we do that.

 Fow now, unless somebody has a better idea, my plan is to get my 
implementation to a ready state and try a somewhat real-world case with a 
real-world app (it'd be nice to have somebody to help with this from the app 
side, whichever app that might be, *hint* *hint*). There are more things to 
do and test than just the transport and if you have a better transport by the 
time other problems are solved, fine with me.

 Norbert: Uhmm ... I guess the same applies to you. It seems like syncing two 
unfinished yet so small things is not worth the trouble now.

-- 
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/