"default" object path

[David Zeuthen]

On Fri, 2009-10-16 at 20:25 +0000, Colin Walters wrote:
> On Fri, Oct 16, 2009 at 8:02 PM, David Zeuthen <david at fubar.dk> wrote:
> >
> > We have bash-completion support in dbus-send [1]. It solves all of these
> > problems. IOW, let's not add features to the protocol / spec when we can
> > just as easily fix the tools.
> 
> That helps, I agree, but it's not quite the same thing; I could
> imagine the concept of the "default" object being useful for scripts
> and bindings, not just interactive sessions.
> 
> For example, it'd be nice if you knew that in a script:
> 
> dbus-send --print-reply org.freedesktop.DBus ListNames
> 
> would continue to do the same thing even in the face of possible new
> interfaces on the bus (as is being discussed), etc.

For non-interactive use you are supposed to be adhering to the API
contract which should state exactly what the well-known path of (one or
more) objects is. Do you have anything more specific than "scripts and
bindings" in mind?

I think adding something like this is really a slippery slope - if we
add this some people use this feature instead of adhering to the API
contract and then they can run into unintended consequences if another
"default object" is suddenly added.

Now, it's true that most services don't really makes it easy to figure
out what the API contract is and, sure, this feature would help
alleviate that problem. But I think it would be better to just beat such
people with a stick and make them document their APIs. Writing better
tools to e.g. generate Docbook/HTML/whatever from IDL/Introspection XML
is a step in this direction (see e.g. eggdbus-binding-tool(1)). Giving
such people a free ride is a step back. </tangential-paragraph>

     David