IDL language

Matthew Johnson dbus at matthew.ath.cx
Mon May 11 05:41:02 PDT 2009


On Mon May 11 13:21, Mark Doffman wrote:
> This IDL shouldn't carry too much information about the way a protocol
> is mapped to the language or library, but should include some extra
> annotation such as struct and enum types that are pretty universally
> useful. The ability to describe new complex types and use them in D-Bus
> messages is a gaping hole in the D-Bus XML, affecting both the protocol
> documentation and the ability to generate decent bindings. Telepathy
> added annotations for this, EggDBus did too.

So, we can just use introspection with some standard annotations? Job
done, don't need to write a new language

> It should look, IMHO, much like the examples in:
> 
> git://git.codethink.co.uk/git/didl
> 
> Now, the only reason you would want to have a typlib (Binrary or
> simplified representation of the information contained in the IDL) is
> for speed purposes. Think of the typelib as a pre-parsed version of the
> IDL. The pre-parsing and all the work of providing ANOTHER
> representation of the information is only really useful for dynamically
> importing the module. When you are statically generating Java bindings
> why not just parse the IDL itself.
 
Ah, I see we disagree about the meaning of 'typlib'. I don't really mind
what format it's in, but I think it should exist. A directory of
introspection files or of IDL files is fine.

However, why not parse IDL itself? Well, I already have an introspection
parser, so if I can use that I don't have to write another one...

> About the 'Standard' IDL though. We don't need to standardize one like
> the OMG did. We can just write one, evangelize it, and hope service
> providers start using it. Having a standard place to install the IDL
> files is the only thing we need to do from there.

Well, I really want to be able to pick any random dbus program and be
able to point at a standard place and a standard format and generate
stubs from it. This suggests we should have a standard format. Of course
I'm using introspection data just fine right now (but naming structs and
filling enums would be nice), so I'm happy with introspection+fluff.

> Different folks different strokes. For Java only client and server this
> makes complete sense. For multi-language stuff I think its usually
> easier to start with the language agnostic bit in the middle.

If people want this, then by all means, and I certainly agree that XML
is not an editable format. I just have slight reservations about pushing
a new format elsewhere, which is why I'd quite like the format which is
distributed for people to generate bindings from (as opposed to writing
new APIs) to remain the XML.

Matt

-- 
www.matthew.ath.cx
D-Bus Java
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090511/06393442/attachment.pgp 


More information about the dbus mailing list