IDL language

[David Zeuthen]

On Fri, 2009-05-08 at 09:50 -0400, Schmottlach, Glenn wrote:
> One thing that might be missing is a mechanism (or tag) a code
> generator could use to determine whether a method (for a generated
> client proxy or server stub) should be generated with asynchronous
> support. I know the C++ code generator I'm working with looks for
> annotations which indicate whether the code it generates should
> support sync vs. async calling/response mechanisms. Should something
> like this be included in the IDL in order to provide a hint so the
> most optimized code can be produced?

First, my view is that all code dealing with calling into other
processes should be async and people should avoid providing sync
versions at all. Except maybe for threads, sync versions are useful. So,
I expect bindings to provide both sync and async variants (and perhaps
guard the sync versions behind a G_DISABLE_SYNC_VERSIONS thing or
something).

Second, I believe that people can just do things like

 @org.freedesktop.DBus.GLib.Async
 SomeMethod(in int32 foo, out string bar);

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.

Anyway, I think that code generators should have a way to set this (for
a single or multiple methods) without users having to change the IDL
(the idea is that people will use IDL docs installed in /usr/share so
it's not feasible to have the user edit them).

Anyway, I don't think we should have any binding independent tags for
specifying this kind of stuff; I think it all lies in the realm of how a
certain D-Bus binding work.

    David