D/BUS IDL compiler ...
Mon, 08 Mar 2004 15:31:02 +0100
> l=F6r 2004-03-06 klockan 16.53 skrev Havoc Pennington:
> My thought was to only do IDL for Qt/GLib bindings, and to use the
> native object representations, IDL formats, introspection data, and so
> forth for those such as they exist.
> For GLib I wanted to do it the same way Qt works, that is:
> - parse a regular GObject to obtain introspection and marshaling data
> sufficient to invoke its methods
> - store this introspection/marshaling data in a variable
> - dynamically dispatch incoming DBusMessage based on said data
> The key insight discussed on this list before is that moc is not in fac=
> a preprocessor; it's a metadata extractor. It creates a variable in the
> final C++ file containing dynamic introspection information.
> That's why in Qt you have dynamic introspection without writing an IDL
> Obviously to do this with GObject we would require following some fairl=
> strict coding conventions, e.g. you could not name your objects
> incorrectly or use types that don't map to dbus types.
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.
> This is all on the *server* side - for the client side, I was just usin=
> 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.
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.
Richard Hult firstname.lastname@example.org