IDL language

[David Zeuthen]

Hi,

That's a useful explanation, thanks for writing it up. It's especially
useful because I think don't a lot of people really regarded D-Bus
introspection XML blobs as typelibs and what the bigger plan was. So
thanks for clearing that up.

One thing I don't like about this setup is that you'll get different XML
depending on whether you do Introspect() or look in the typelib repo. I
guess that's an OK tradeoff.. at least you only need one parser for the
whole shebang. It might, though, surprise people and some bindings might
(inadvertently or not) spit out more stuff via Introspect() than they
should. I guess that would just be bugs to be fixed.

Another thing I don't like is that people are going to keep using
anonymous structures because it's fine for the languages they care about
(e.g. not C or C++). I suppose that can be fixed by either command line
arguments to code generators and typelib addition requests. So it might
not be a big deal.

Finally, I'm concerned that there's a bunch of work in actually making
this whole typelib idea fly (I think it's more work than just installing
randomly named files into /usr/share/dbus-1/interfaces - we'd need to
spec out some things).

Anyway, I'm still going to iterate over the IDL language my original
mail was about, because, well, I think it's an useful thing if you are
doing level 2 and level 3 stuff (and in the free desktop, we mostly only
have level2/level3 users right now - for better and worse) or if you are
using languages like C.

Making the IDL compiler both read and write these socalled typelibs
sounds useful too; I'll send some mail when it can do that. Then we can
iterate over what kind of additions I made, we want in the spec. Unless,
that is, you are already opposed to the already suggested additions
(that would be struct, dynamic_struct, enum, error_domain)?

    David