IDL language

[Schmottlach, Glenn]

> Second, I believe that people can just do things like
> 
>  @org.freedesktop.DBus.GLib.Async
>  SomeMethod(in int32 foo, out string bar);

>> I dislike having binding-specific annotations whereby you have to
edit
>> the IDL before converting it to stubs in your language. It's hardly
>> _independent_ at that point...

I don't particularly like it either but without some mechanism to
indicate which methods should have sync/async proxy/stub bindings
generated, each language binding will "invent" their own IDL with
proprietary extensions (unless, of course, you have another
recommendation). In many cases you don't want the language binding to
generate both sync and async methods in order to optimize the amount of
generated code.

> to do this. E.g. the annotation mechanism is extensible. Whether this
> means that the server stub is sync/async or the client proxy is
> sync/async is also an interesting question.

> This is another point against these annotations, or maybe that just
bad
> overloading of the annotation used in the current glib binding

Again, I'd love to hear an alternative suggestion. How does a code
generator know what to do without some sort of hint? Should this be
specified in (yet another) configuration/IDL file that is binding
specific?