"default" object path

[David Zeuthen]

On Sat, 2009-10-17 at 09:18 +0200, Thiago Macieira wrote:
> This is assuming that clients need to know which service it was. I don't see 
> why they need to. Now the manager object just needs to apply to all objects in 
> the same connection: i.e. a "ServiceIsIdle" signal would be emitted when both 
> of the services are idle now.
> 
> Besides, you can still differentiate by interface. You're assuming that the 
> same interface is used by the manager object in both services. If we assume 
> that, then I'd argue that merging the services into one common manager object 
> also works just fine.
> 
> If they had different interfaces, then nothing changed because you can still 
> tell which one is which.

Both of your suggestions require either breaking the semantics or the
syntax of each service. E.g. ABI breaks. And in some cases it might not
be possible - the signal on the hypothetical org.fd.Service could be in
a form where you just can't consolidate both services into one (consider
a signal ServiceDescriptionChanged(STRING) - where Description is some
human-readable description of the service).

I'm not making this up, btw.

A more realistic example would be a standardized D-Bus interfaces for
the "agent registration" pattern - one example is in polkit with the
RegisterAuthentication() and UnregisterAuthenticationAgent() methods and
the AuthenticationAgent D-Bus interface [1]. Other examples includes the
Bluez stack. It would be *useful* to have a standardized interface for
this so the various toolkit stacks out there (e.g. the G stack, Qt and
so on) could provide helper classes / utility for using it.

Also, people, especially those working on embedded platforms, *are*
going to want to reduce the number of processes running at both the
system- and login-session-level. E.g. it's a bit expensive to have N
daemons for providing N services - it's better to consolidate such
things into a single process (gnome-settings-daemon for example) where
it's appropriate.

Anyway, you are free to keep pretending that it's a good idea to just
register objects at '/'. You just get to keep both pieces when something
breaks ;-)

     David

[1] :
http://hal.freedesktop.org/docs/polkit/eggdbus-interface-org.freedesktop.PolicyKit1.Authority.html#eggdbus-method-org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent
http://hal.freedesktop.org/docs/polkit/eggdbus-interface-org.freedesktop.PolicyKit1.AuthenticationAgent.html


> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus