wufan9418 at gmail.com
Fri Aug 17 13:29:25 PDT 2007
I can only speak for myself here. The reason I'm looking at gbus is
mainly for the support of proxy and name/signal/owner tracker. Since
I'm going to use threads, I don't feel less convenient without the
> Anyway, a final thought - again I think the app author should have to
> type only two things, ideally: the declarative information such as the
> name they want to own and the "style" of owning it; and the actual
> application logic in callbacks.
If that is the case you can go further by getting rid of all the
register/unregister calls, and ask user to fill in a big table which
has all the callback/type/path/name information, and then pass the
table to a dbus_start() which will set up the loop and get the
connection and call the callbacks if needed.
> The point is that you could register multiple NameOwner objects and
> data for the same owned_name. So only the first one matching the
> passed-in NameOwner and data would be unregistered.
Why would you need multiple NameOwner objects for one name?
> I would not do this; you want to do the same thing in NameLost and on
> initial failure to get the name. The point is, if you don't own the
> name you would exit or stop providing services related to that name.
> If you do own the name, you would keep running to provide services
> related to that name.
The difference between NameLost and FailedToAcquire is, for NameLost
most likely something needs to be cleaned up before exit; while for
FailedToAcquire, probably nothing has been started yet so the clean up
can be saved. I would say some application might appreciate the extra
information, if just for logging purpose.
More information about the dbus