IDL language

[Havoc Pennington]

Hi,

On Fri, May 8, 2009 at 10:08 PM, David Zeuthen <david at fubar.dk> wrote:
> 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.

Right. There's nothing to stop a binding from just sending the stuff
from the typelib directory in response to Introspect(); and there's
nothing to stop a binding from always looking in the typelib repo
instead of calling Introspect(). I'm not really sure Introspect() is
that useful, to be honest... I think you usually do need to know the
typelib statically - even for dynamic languages. With dynamic
languages you never need to type the typelib in, but it's still
"implied" by the code, even at "level 1"

But Introspect() is at least handy for dfeet and such.

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

Yeah, I find that named structures are more pain than gain... I'd tend
to almost always use a dictionary instead, and something hash-like in
C/C++ is not that bad. The main reason to use a structure instead of a
dictionary is when you are just shoveling big hunks of data, like an
array of points. But in those cases, I don't know - I don't like
having "IPC" types leak all over an app, that was certainly a mess in
CORBA, and I'd tend to hand-code a struct and manually convert the IPC
stuff into it. Or tend to want GdkRectangle or QRect, not "struct
orgFreedesktopRectangle" or something.

If people want to put named struct hints in the typelib and use them,
it doesn't really bother me as long as it isn't mandatory, but it also
doesn't really bother me if people don't do this. For me it's
basically a C/C++ specific feature, much like a "C symbol to use"
annotation would be.

A thing to remember is that dbus is already quite a lot more complex
than many IPC systems that Work Fine (tm) from DCOP to XML-RPC to
JSON. It just isn't true, often, that extra complexity is really
needed.

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

Definitely there is. But any solution here is work.

> 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)?

I'm not a fan / don't really get the aspect of dynamic_struct where
the struct name is included in what's sent over the wire.
An annotation that just said "treat this dictionary as a struct with
these fields" would make more sense to me (define the struct in the
typelib, then annotate that certain dictionaries are serializations of
that struct, yes... but type-tagging the dictionaries is klunky imo).
Including the struct name in the wire data starts to feel like we're
tunneling a CORBA-like thing through dbus or something. I'd do it as a
hint, where some code ignorant of the hint would just get a dict and
work with the dict, and a code generator that knew about the hint
could use it.

@ArgTypeHints(['org.freedesktop.MyStruct'])
Foo(dict<string,variant> myStruct);

Anyway, as long as annotations are hints and additional descriptions,
I don't mind them much. They can even be binding-specific. Anyone who
wants to ignore them can do so.

These things are mostly not in the common spec because nobody's ever
really wrestled the discussion to the ground and written up the spec
patches. (For that matter, I don't even remember if the XML format is
really specified...)

Havoc