IDL language

[Mark Doffman]

Hi Matthew,

> 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

:) Thats pretty much the approach people have been taking so-far. Davids
 proposal for a typelib I guess looks a-lot like that.

See bottom: "XML is not an editable format"

I want something that is editable and readable, even in its source form.
If people want to standardize on some annotations that describe structs
& enums I'll have a backend for the IDL that compiles down to it. Its my
intention to compile to the EggDBus XML as a first-go.

> 
>> 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...

You'll have to modify your introspection parser whatever format is
'Chosen'. However I think the people writing the IDL parser should make
it easy to add back-ends. Thats certainly my intention.

> 
>> 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.

Point taken, there is a benefit to encouraging dbus services to declare
the protocol in a standard format. We do that already with the D-Bus
introspection XML. Why not just have a standard location for installing
these?

I personally think that the added information or 'fluff', would be very
useful. I don't think there is enough information in the XML to generate
decent bindings. Of course there isn't a 'right' or 'wrong' here. The
more information we include the more restrictive we are being about how
D-Bus should be used within a language, and we make more work for people
writing a D-Bus protocol directly. The less information that goes in the
harder it is to pick a random d-bus program and generate decent stubs
for it. The current XML is bare-minimum, on-the-wire stuff. (Except for
the odd inclusion of properties).

Thanks

Mark