IDL language

[Thiago Macieira]

Em Sexta-feira 08 Maio 2009, às 15:50:21, Schmottlach, Glenn escreveu:
> This looks like a great start along the lines of a common IDL.
>
> 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?

While I agree that there should be support for generic annotations, I'd 
deciding whether a given method should be asynchronous or not is a decision to 
be made per usage, not for all.

In fact, we could say that for almost all annotations that are  hints to code 
generators. But some of them are more permanent than others, like indicating 
which library type should match a given D-Bus complex signature.

However, I don't think deciding on synchronous or asynchronous is a permanent 
decision. Some applications may want to call it synchronously and some others 
may want asynchronously. Some may want to do both, even. So this decision 
should be made when generating code, by supplying the code generator extra 
information, besides the interface definition. (this discussion is orthogonal 
to IDL vs XML)

In time, QtDBus starting with version 4.5 solved this problem by not deciding 
at all. All methods are callable in both ways and the decision is made after 
the call is placed. The generated code returns a structure representing a 
DBusPendingCall. With that value, you can decide to synchronously wait for the 
call to finish (method waitForFinished(), matching the API 
dbus_pending_call_block), or you can choose to be notified when it does via Qt 
signal. Trying to access the contents of the reply does an automatic and 
implicit waitForFinished().

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Software
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090508/a477d97d/attachment.pgp