asynchronous error reporting

[Robert McQueen]

Havoc Pennington wrote:
> Hi,
> 
> I think you should ask the fundamental question, are your signals/errors
> associated with a particular method invocation, or are they "global" and
> potentially of interest to someone other than the method caller.
> 
> If they are fundamentally a reply to a particular method call, you
> should really just do an async reply to that method call.

I've been looking mostly at the python bindings (although I now have
about 10 patches to push up) and I didn't see a way of doing this. As
Ross pointed out, the glib bindings do allow async replies, and I've
just discovered that I have a need to do this in my interface, patch 11
for the python bindings will probably appear over the weekend.

> If they are fundamentally global, then you could just add an "error"
> signal that sends out some error that happened.

Yes, there will be some of these.

> If you're putting a "method call ID" in a signal I think that's probably
> a sign of a completely broken interface design ;-)

This is what I'm trying to avoid by asking these questions now. It would
be totally unusable from any sensible bindings anyway. I already have
interface names in places and this upsets me a reasonable amount.

> Havoc

Regards,
Rob