IDL language

[David Zeuthen]

On Fri, 2009-05-08 at 10:28 -0400, Schmottlach, Glenn wrote:
> > 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?

Ideally, binding generators wouldn't need these kinds of hints from the
IDL.

E.g. for the client side you can always generate BarProxy.invoke_foo()
and BarProxy.invoke_foo_sync() and on the server side maybe you can
always generate

 // abstract interface class for D-Bus interface Bar
 class BarInterface {
   virtual void handle_foo(MethodInvocation &m, ...);
   virtual void handle_foo_sync(MethodInvocation &m, ...);
 };

and then the user can subclass BarInterface and implement the vfunc he
wants (e.g. your default impl (not overridden by the user) would throw
an exception or something). Maybe you also want handle_foo_in_thread(),
handle_foo_in_fiber() variants, I don't know.

Anyway, I'm hand-waving on purpose here. The point is that you can
handle this without having to specify it in the IDL.

    David