[IAEP] fixing etoys

[Bernie Innocenti]

Yoshiki Ohshima wrote:
>   Again, start up time is not a problem.  Etoys start up looks a bit
> slow on XO, but that is because the DBus communication that has to be
> done.

I frequently hear DBus being accused of latency.  As badly
implemented as it might be, I can't believe a daemon relaying
a bunch of bytes over a UNIX domain socket can introduce more
than 1ms of lag per message, even on a very slow processor.

Has anybody ever analyzed the actual DBus traffic?  With timings?
How many messages are we talking about?

It might very well be that the event loop on one of the endpoints
is misbehaving and not waking up the process immediately when
the socket has incoming data.  This is not at all unusual in
applications that mix GUI and networking, but I don't know the
specific interactions of gtk, dbus and the python bindings.

Also, I'd like to check if we could do anything to reduce our
dependence on DBus to provide basic desktop services for which
there are existing Freedesktop standards and long established
X conventions.

If we manage to make DBus entirely optional, the initial effort
of porting a Linux applications to Sugar would be greatly
simplified.

Yes, one could wrap the thing in libsugarize, but why resort to
a kludge when there are standards we could fall back to?

-- 
   \___/  Bernie Innocenti - http://www.codewiz.org/
  _| X |  Sugar Labs Team  - http://www.sugarlabs.org/
  \|_O_|  "It's an education project, not a laptop project!"