D/BUS IDL compiler ... #2 ...

[Owen Fraser-Green]

Hi,

> The human-readable IDL is just a language binding that chooses to have
> the programmer write an IDL file and then generate the native language
> file from that, instead of parsing the native language file. In other
> words the IDL in this case is really specifying an implementation not an
> interface ;-)

I've been thinking this over a little and it occurred to me that maybe
you were really onto something here. The IDL described here up to now is
similar to that used in CORBA and elsewhere in distributed component
systems. It's concerned with the specification of types and interfaces
and it's useful to clients which see that the Foo type looks interesting
so let's create an instance, foo, and start using it.

D-BUS is a little different. It's a bus and it isn't really concerned
with remote object instantiation. As a client, I can't say 'Foo foo =
new Foo()', I say 'GetObject("/org/freedesktop/Foo")'. Therefore, I
think that the description language should begin by describing the
well-known objects a service provides. Then, it can go on to describe
the interfaces they implement. This is akin to using object diagrams in
UML to describe the system state and then backing it up with some class
diagrams.

To coin an example, HAL has an object "org/freedesktop/Hal/Manager"
which implements the interface org.freedesktop.Hal.Manager. There is,
and will only ever be, this one object which implements
org.freedesktop.Hal.Manager and the xDL should describe that.

Another thing is OBJECT_PATH types. I don't think it suffices for the
xDL to simply denote that an OBJECT_PATH is passed. I think it should
state what interfaces are implemented by those objects referenced by the
path probably using the same syntax as that which would be used above.
Unfortunately, I'm not going to go as far as to put my money where my
mouth is and actually suggest a syntax :)

> Maybe the right thing to do then is declare that IDL is never installed,
> and neither are the XML files; IDL is only something written in your
> source tree as a way to generate C files, the XML is only the
> Introspect() return value.

If it can be used to publish the location of the well-known objects I
think XML file could actually be rather useful. In fact, if they went
into a standard repository, maybe they could serve instead of the
introspection sorely missed by Mr Schotanus on this list last week.
Maybe there could even be a D-BUS interface to that repository.

Just a thought.

Cheers,
Owen