Errors and the introspection format

Havoc Pennington hp at
Mon Feb 20 08:19:05 PST 2006

On Mon, 2006-02-20 at 13:29 +0000, Daniel P. Berrange wrote:
> Actually I think it has to appear in the introspection data, even though
> it is a property of the client code. In dynamic languages which generate
> the remote method proxies on the fly, the client bindings would read the 
> "no reply" hint at runtime to decide whether to do a fire & forget call.

But why would the interface provider know this? It's purely at the
discretion of the user of the interface, how they want to make a call at
a particular place in their app. If I provide "void Frobate()" I have no
real basis for choosing noreply or with-reply.

I think maybe at some point we had some idea about "merging" xml files,
so the point was that the interface provider/publisher would install
just the interface aspects, and app developers could "merge" stuff that
was specific to how to generate a particular binding in their app. Some
mechanism like that could be useful.

For dynamic bindings for now, I think it'd be better to ignore NoReply
received over the wire, and just let app developers specify it
programmatically somehow. You could generate every method all three
possible ways, is one approach:

  class Foo:

    def Frobate():
       // round-trip blocks

    def Frobate_noreply():
       // fire-and-forget

    def Frobate_async():
       // send, and return a "pending call" object

For languages where you can generate the methods "on demand" instead of
up front, that seems especially appealing, since there's no real reason
_not_ to do it...


More information about the dbus mailing list