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

[Patrick Williams]

On Wed, Jul 13, 2022 at 01:17:10PM +0300, Alexander Amelkin wrote:
> As a side note to this discussion, have we considered using shorter and 
> more convenient paths for dbus?
> 
> 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.

>> 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.

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

> 
> 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".

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220713/ddcd5a28/attachment.sig>