[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: message bus code

Thanks for that Havoc, very interesting stuff. I've gone through the
archives and am now caught up with what's going on, I'll check out the
code later.

Actually most of my comments are on the component model ideas, rather
than DBUS itself (which seems to be progressing nicely, and all the
decisions seem pretty sensible). Be warned, if you're in a hurry this
email is more general comments and speculation rather than hard talk
about the code/message format etc.

I've been considering something like the Hub for about a year on and
off, so it was pretty cool to see a lot of what I'd concluded written
down, too bad I didn't discover it before really :)

I eventually settled on a design that routed objects via GObject, as
being based on C it was basically accessible to all languages including
C, which a C++ based solution wouldn't have been, and the GObject
feature set is relatively close to what modern languages have (ie no
multiple inheritance, signals and so on). The IDL took the form of some
XML placed in a well known location that contained typing data, as well
as potentially API docs and extra data that's useful to have for
optimizations etc.

When I say "routed" I'm not talking about anything fancy (i'm not a
fancy coder :/), it simply relied on an intermediate shared library that
contained code for loading the object and then exposing it via GObject.

So for instance, if I write an object in C#, and want to make it
available to C, I can run a tool which introspects the object (either
via source analysis or for .net apps loading them into the runtime and
introspecting that way) and produces the IDL/XML file necessary, as well
as a mini shared lib project complete with autotools machinery. The
shared lib contains the headers the define a Gobject, and code that
links against libmono then loads the object into runtime. The
type/exception handling etc stuff is dealt with by the glue code.

Not particularly elegant, but for languages like C, C++ and Objective-C
which need typing info available at compile time it's kind of
unavoidable without rather evil dynamic link time tricks, or interface
based approaches like COM.

For dynamic languages like Python, when you request a class it loads the
description file, and uses a set of well known mangling rules to locate
and link to the GObject methods/constructors etc, and then proceeds to
build the object into the runtime. So 1 line of python that gets a class
is actually responsible for loading the mono runtime into the address
space of the python interpreter.

That's about where I got up to, I didn't give much thought to more than
2 languages interoperating in that way, nor the details of memory
management or exception handling. C++ support could be done by having
the glue library actually written and compiled by a c++ compiler
producing a binary that exports both GObject and C++ symbols.

Cross-language inheritance was kind of doable in this system, as the
object would end up being exposed via the languages native class system.
I never really explored the details though.
The obvious disadvantage is that you always need glue code, even if both
the languages in use are capable of building objects at runtime, simply
to deal with smoothing the creases. Perhaps optimizations in the
language bindings could figure out for instance if you're loading .net
from python and do it directly, but you still need the central joining
point, otherwise for every language you have to update every binding.

On the other hand, I've always considered that far more likely to
actually happen in the real world than everybody moving to .NET which
would of course leave the huge amount of code written in C behind. For
instance currently the Mono team use libxslt for transformations but I
think the long term plan is to write a .NET implementation, because
libxslt can only process XML it loaded itself, and because it doesn't
use the .NET XPath classes. CORBA/Bonobo style has been tried and found
somewhat lacking so despite the general lack of elegance I think it's an
approach that bears thinking about.

As for packaging, well by the time something like that actually happens,
hopefully me and my friends will have developed something useful there
(we are designing for flexibility so themes/docs/components etc can be
installed as well as binaries). We're leveraging off of DNS for our
naming stuff, ie "@gnome.org/gedit" which is similar to the mozilla
style. Java style reverse DNS works well also.

I think it definately works better than GUIDs or naming authorities, at
least we're all reasonably familiar with DNS style names and it's pretty
decentralised, the only real issue being that if you use for instance
"@cs.durham.ac.uk/foo" then when you stop being a student at durham
university that name effectively becomes no longer yours.... GUIDs get
around that but at the cost of being incredibly cumbersome, so perhaps a
human-readable -> GUID mapping.

A shared component model is most definately a long term goal though.
It'd be great to reduce the amount of code duplication, but things seem
to be chugging along OK as they are, and a message bus system would have
a far more immediate impact in terms of improving user experience as
well, so it's good to see work being done on that.

thanks -mike

Mike Hearn <mike theoretic com>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]