D/BUS IDL compiler ...

[Havoc Pennington]

On Mon, 2004-03-08 at 09:31, Richard Hult wrote:
> 
> Did your plan include a way to map structs to dicts or some other way to
> pass more complex data than just the primitive types?
> 
> It could be tricky to get right, but potentially very useful. We would
> definitely need strict rules for that to work.

First question is how do you represent that data in the native (Python,
GType, Qt, CORBA, C#, ...) type system. Then we stuff it through dbus
somehow.

This seems orthogonal to the IDL issue to me, since the IDL issue is
about what the native type system is in the "IDL binding", and the
complex-types-in-dbus is about how you represent a complex native type
over the dbus wire.

I don't like the dict thing all that much, seems to me either we stick
to only basic types (primitives and recursive arrays thereof) or we
should add structs. Some native type systems e.g. python could treat a
struct as a dict.

We could do structs without requiring an IDL spec for the struct type,
as in XML-RPC:
http://www.xmlrpc.com/spec

i.e. basically the same thing as a dict, except call it a struct and
expect a struct mapping in languages that have it. There's no type tag
for "struct Foo" though, that is only in the binding, not on the dbus
layer.

An alternate approach is of course to use DBUS_TYPE_CUSTOM

XPCOM doesn't allow complex types for interfaces available to JavaScript
(those tagged "[scriptable]") so I'm not sure disallowing complex types
is quite as bad as people seem to feel it is, mozilla is pretty huge and
limps along.

> > This is all on the *server* side - for the client side, I was just using
> > varargs, as the typesafe C function wrappers create makefile complexity
> > and code size. See dbus_gproxy_*
> > 
> > If you did typesafe wrappers I'd do those as an opaque typedef that was
> > cast back to DBusGProxy inside the wrapper.
> 
> I'd say that client side wrappers are pretty important, since hopefully
> a lot of code will expose a dbus API. If we want people to use those
> APIs, typesafe non-string APIs would make a lot of sense.

Sure, probably sensible. I think it's nice to be able to code something
quickly without worrying about generating header files though.

Generating C header files either requires the C header file be installed
by the service provider (generate the header from the same file that
implements the service), or that we install some sort of IDL or type
library so the header can be generated later.

My suggestion would be to install the same XML format returned from
Introspect(), i.e. an XML type library. And scripting languages need not
know where or how this crap is installed since they can just call
Introspect() at runtime.

> Regarding makefile complexity, shouldn't it be possible to get the
> complexity down a bit by providing m4 macros a la intltool? That way we
> would only need to get it right once instead of duplicating the extra 20
> lines in all makefiles of modules that use dbus.

Agreed.

It's all pretty academic at the moment until we start making a dent in
doc/TODO...

Havoc