dbus prefixes (was: DBus ObjectManager Interface usages within the project)

[Alexander Amelkin]

13.07.2022 14:39, Patrick Williams пишет:
> On Wed, Jul 13, 2022 at 01:17:10PM +0300, Alexander Amelkin wrote:
>> I don't see any real reason for the project to be using this long and
>> cumbersome /xyz/openbmc_project/ prefix.
>> Why not use just '/obmc/' or `/phosphor/` ? I believe that would be more
>> than enough to separate all our services from any third-party ones on d-bus.
> FWIW, it isn't required but it is encouraged to use a reverse-domain prefix on
> paths by the dbus spec itself.

Yes, I'm aware of that. But do we actually need to follow that 
recommendation? What for?
I believe, it exists and is encouraged for big open systems to avoid 
conflicts between different pieces of software using d-bus simultaneously.

As I said, OpenBMC is a closed system where the set of software is well 
controlled. We know beforehand what software uses which prefix. I find 
this just inconvenient to use the long prefixes in these circumstances.

>
>>> Object paths are often namespaced by starting with a reversed domain
>>> name...
>> I understand why this prefixing is for in 'big' open desktop or server
>> systems where there on d-bus can be any number of software from any
>> number of vendors. In an embedded system, such as OpenBMC, on the
>> contrary, the set of software using d-bus is strictly limited and we
>> always know beforehand what prefixes are used. I'm pretty sure none of
>> the software included into OpenBMC builds will ever use '/obmc' prefix.
>> So why continue using the inconvenient long prefixes when it is safe to
>> use short ones? I would even propose dropping all prefixes at all, but
>> ok, let's pretend that there can be some other 3rd-party 'Inventory'
>> than '/obmc/' ('/xyz/openbmc_project/').
> Generally speaking, isn't the content in a single process pretty well
> known no matter the type of system the daemon is installed on?  I think
> it is pretty rare for a shared library to create its own dbus objects
> and if it did it'd probably create its own bus-connection too.  I'm not
> sure what is unique about a desktop vs embedded system in this
> discussion.

It's rather that embedded system is unique compared to desktop.

Desktops, if not enforced to use reverse domain prefixes, may end up 
using the same name for a d-bus service if two different software 
authors decide to use the same word. The probability of such a 
coincidence in a desktop is quite high. That's why d-bus spec encourages 
use of reverse domain notation (relying on uniqueness of domain names 
and their binding through registration to physical bodies or legal 
entities).

In embedded systems the probability of that coincidence is negligible on 
the other hand.

> What are we saving by switching to something shorter?  Can you
> elaborate?  It seems like it is mostly just typing...

I guess you're right that it's mostly just typing that we save. That's 
actually a lot when we're talking debugging and running busctl 
repeatedly with changing parameters from a command line.

It may be also that we are achieving some better code readability by 
dropping the identical long prefixes and only leaving what's essential.

At least for me that is important.

>
>> Am I wrong or missing anything? What's stopping us from switching to a
>> shorter prefix, aside from the existing code that will need to be
>> changed to it?
>>
>> The same proposal/question actually applies to service names (e.g.
>> xyz.openbmc_project.ObjectMapper could easily become just
>> obmc.ObjectMapper or phosphor.ObjectMapper), let alone just 'ObjectMapper'.
> Service names and interface names have a strong statement w.r.t
> reverse-domain prefixes.
>>> Interface names should start with the reversed DNS domain name of the
>>> author of the interface (in lower-case), like interface names in
>>> Java.
>>> Like interface names, well-known bus names should start with the
>>> reversed DNS domain name of the author of the interface (in
>>> lower-case)...
> Assuming the typical use of "should" it means "this should be done
> unless you have a good reason not to".

Again, why (for what purpose) do we have to obey those statements?
What exactly are we achieving by obeying them? Do we need to achieve that?

We're creating a closed system that does not interact with any external 
software using d-bus.

IMO, we're completely free to choose the notation of service and interface
names as we see fit. We won't be introducing any disturbance into the
outside world by not using the general purpose notation. No one would 
actually
even notice us doing that.

WBR, Alexander.