Remarks on the Work of Sugar

[Michael Stone]

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