Object paths naming conventions?

[Havoc Pennington]

Hi,

On Thu, Jul 17, 2008 at 6:20 PM, David Stockwell
<dstockwell at frequency-one.com> wrote:
> However, what I thought I was trying to convey is NOT that "/" (or any other
> path) is now owned globally by org.bluez, but that it must be unique within
> org.bluez  Is that correct?

"/" would have to be available within a process implementing the bluez
spec. If two specs both use "/" (we just saw two in this thread), then
a process will not be able to use both of those specs. For the case of
bluez and that media player spec, using both seems unlikely. But it's
pretty easy to imagine specs that _are_ useful to use together.

As long as everyone polluting the object namespace writes specs that
nobody wants to use together, then it's fine. Just as if I write two
shared libs that use the same symbols, it's fine, as long as nobody
uses those libs together.

But, in most cases, programmers agree that it's a bad practice to skip
namespacing just because most likely nobody is using the same names at
the moment.

> Incidentally, it does appear (my experimentation) that DBus allows for some
> polymorphism in method calls (e.g., optional parameters).  Is this
> intentional?  It also appears that the some/most of bindings do not support
> this...

It is intentional; the dbus design is to do no checking on the
protocol or daemon level for conformance to any interface - to use an
XML analogy, libdbus and dbus-daemon only care about well-formedness,
not validation. This avoids a mandatory interface repository (global
typelib registry).

However, in practice if you're providing interfaces you want arbitrary
apps to be able to use, you should stick to stuff that makes sense in
most programming languages. It's best to avoid variable-length
argument lists and just generally keep it simple.

Havoc