Monitoring lifetimes with Python bindings

[Ole Laursen]

(I am resending this message from July 10, apparently it got stuck in
my local Exim mail queue.)

"John (J5) Palmieri" <johnp at redhat.com> writes:

> While we may need to expose things like sender I am hesitant to do
> so for this example. I would however not be opposed to creating an
> API for keeping track of name owner changes, disconnections and
> reconnection's. So say something like:
>
> bus.watch_for_disconnect("org.foo.Bar", on_disconnect)
> bus.watch_for_name_owner_change("org.for.Bar", on_name_owner_change)

That sounds great, as long as they take care of the race condition
(i.e. probe for whether "org.foo.Bar" is there and emit the signal if
not), else the benefit is miniscule.

> Anyway, for your problem right now you might want your server to have an
> API where clients can register themselves so you don't have to worry
> about the sender object:

I don't think that helps me, because the server needs to know what
parts of the UI it should remove when a client fails. And currently it
has no way of knowing who is contacting it when it receives a remote
invocation. Another reason why I wouldn't want something like a
register_object function in the long run, is that it complicates the
client in case of failures since it then may have to reregister. I'm
hoping to have near stateless clients.

For now, I will just let the client redundantly pass its name as an extra
parameter when it contacts the server.

> I need to sit down and think things through before I start adding new
> API.

I hope you will come to the conclusion that being able to know who
contacted you in a distributed scenario is sometimes vital. :-)

-- 
Ole Laursen
http://www.cs.aau.dk/~olau/