On Wed, Jul 23, 2008 at 12:56:39AM -0400, Polychronis Ypodimatopoulos wrote: > On another note, should we look into Google's protobufs > (http://code.google.com/p/protobuf/) to be used as structures to be > passed in inter-process calls?
While I'm convinced that protocol buffers and their supporting code generators are cute, I'm also convinced that the real issue in the IPC space is not "what marshalling format do you use?" but is, instead, "what tools are available to generate, capture, dissect, and reply to IPC queries?". Unfortunately, I don't care much about generating marshalling code; hence, they don't seem superior to me in the areas that I care about. (see below) > These are essentially "compiled data structures", but I'm not sure if > the trade-off for (de)serializing data is worth it, even if native > code is used to perform the action. I suspect that we'd have to measure to find out [1]. In practice, my suspicion is that Sugar transfers relatively little data over D-Bus but does a lot of work in response to the data that is transferred. The point I was really making was that the current IPC mechanisms make it unnecessarily hard for other people to play with Sugar because the current mechanisms force API consumers to speak a language that they can't "natively" read or write [2]. The consequence of this hidden cost is that Sugar is hard to script and, as a further consequence, hard to build automated tests around. Regards, Michael [1]: Besides, if performance were your ultimate goal, why not avoid that marshalling and copying overhead with shared-memory and semaphores or file descriptor passing or something equally exotic? [2]: I consider web-browsers and Unix shells to be "fluent translators" for the programmers who I expect to be hacking on Sugar as opposed to the dbus-introspection tools which currently seem to me to be like "novice translators". _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar