D/BUS IDL compiler ...

[Havoc Pennington]

On Wed, 2004-03-10 at 05:57, Michael Meeks wrote:
> 	We need a recursive type system anyway IMNSHO. It should really
> simplify the code, (and hopefully chop out the extra 'N' special cases
> for arrays).

It seems inevitable... personally I'd be willing to suck it up and say
only primitive types and TYPE_CUSTOM, but nobody seems to agree with me
other than Matthias.

> 		a) marshal with a non-verbose plain type description of
> 		   the arguments as presently done interspersed with the
> 		   data.

Right, marshal with a type description like "struct of
int,int,bool,string"

Interspersed with data is less clear, there's a TODO to move to do the
protocol like:
 [type descriptions for all args] [data for all args] 
in two separate blocks, with the idea that you can then grab the type
signature in a single block and quickly look up or typecheck the
associated native method. The API already reflects this but the protocol
does not. 

This change is fairly complicated to make because of how the
implementation works. Basically both read and append iterators have to
track two locations, and DBusMessage probably needs a third DBusString
so you have header, typesignature, and body strings. Which then
complicates the send/receive off the wire code. An alternative is to
keep the typesignature in the body string and rely on only having to
realloc() every fourth type byte due to alignment. Or we could specify
that arbitrary padding is allowed after the type signature so the code
can preallocate 8 bytes or so and avoid realloc in most cases.

> 		b) provide the verbose information via introspection.

That's a thought. This probably hinges on whether the struct field names
will be the only reason many bindings need to introspect; if so, I think
it'd be better to keep the names in the type signature somehow so they
can skip the introspect, if they are all introspecting anyway, then the
info may as well be in the introspect info.

> 	Anyhow - I'm intrigued by this 'yet another standard' for XML
> introspection of stuff inspired by D/COP (I assume)[1]. Is the XML
> specified somewhere ? and/or where can I read up on this ?

Most of the code for it is in the glib bindings at the moment. The idea
is to avoid a binary typelib format, and to allow extensible
introspection data, e.g. to include the struct field names or whatever
is required. One reason to use XML was to keep introspection stuff out
of the dbus core and put it all in bindings instead. If you used binary
typelibs you'd need a whole API to work with them, with XML anyone can
parse the thing.

DCOP introspection doesn't use XML it just has multiple specific
methods, like Interfaces() and Methods() that return arrays of strings.
Matthias proposed the XML format as cleaner than this.

Using IDL seems unfriendly to me because it's nontrivial to write an IDL
parser, so e.g. if you're doing the Python binding you'd need to bind to
libIDL and figure libIDL out, or we'd need to install a special
libdbusidlparser, or something like that. While with XML you just use
the standard Python XML parser and it's pretty easy to figure out the
format.

> [1] - It seems curious not to use your own type/marshalling system to
> represent it's own types - but some curious extra XML format

There isn't a full type system in libdbus to use, e.g. there's no API
for manipulating a "typelib" or type signature, and no variant type.
There's only the iterator API to iterate over a DBusMessage. This is
intentional. You're supposed to suck the data out of DBusMessage _into
some other type system_, remember.

A typelib object in libdbus would be a whole big pile of code. XML is
easy to deal with if you're writing a binding, e.g. python can easily
parse it and sort it out. In the places where libdbus implements
Introspect() it's also easy to generate XML without having a special API
for it.

Havoc