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!" _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel