clarity of concept [LWN.net]

clarity of concept

Posted Nov 6, 2014 23:29 UTC (Thu) by iabervon (subscriber, #722)
In reply to: clarity of concept by alexl
Parent article: Kdbus meets linux-kernel

It would be nice if the default interface for a service were the service's name, so you wouldn't have to say, "I want org.freedesktop.timedate1, and I want it to act like a org.freedesktop.timedate1", but could say, "I want org.freedesktop.timedate1 (and I want it to act like itself)".

I think this object path is actually a bit misguided, though. If there were two objects in this service, the most likely situation would be something like what I've got on my desktop, where I've got one clock in the local time zone and one in UTC. Paths like "/clocks/me" and "/clocks/universal" would identify different things that this service would want to manage, while leaving room for other sorts of object that the service might also want to manage (maybe /zoneinfo/Buenos_Aires, to report the system's time zone rules for Buenos Aires, so that you can send someone an iCal meeting and they'll know what you expect the UTC offset to be, in case their system's timezone data isn't the same). If you name your object based on your service name, chances are that, if you ever have a second object, it will have equal claim to that name, defeating the purpose of obligatorily having names.

to post comments

clarity of concept

Posted Nov 7, 2014 1:29 UTC (Fri) by hp (guest, #5220) [Link]

You could do that as a convention in the client library (have a function that takes one name and derives the others from it). There isn't a need for a protocol change for it.

It isn't necessarily good practice for services to have one object with everything in one interface anyhow, though it's probably fine for a very simple service.

The object names are only namespaced because a single process may contain unrelated modules. For example all GTK apps could have objects available under /org/gtk.

If you know your process doesn't have multiple modules you could name an object /foo just as you can have a global variable in C called foo instead of my_namespace_foo. What is "OK" is a judgment developers have to make.

There are also cases where a strategy like naming each object with a GUID or something makes sense.

clarity of concept

Posted Nov 7, 2014 3:44 UTC (Fri) by luto (subscriber, #39314) [Link]

I actually think that the reverse anti-stuttering approach might have been better. These cases are examples where the client wants a singleton object in the context of either the running system or the desktop session. The client doesn't really give a crap what service provides the timezone object; it wants to access the timezone object.

What if there were a pseudo-service org.freedesktop.dbus.singletons with the special property that different real services could register different well-known names under the singletons service.

Then you could talk to /org/freedesktop/timedate1 in the singletons pseudo-service.

Anyway, the stuttering issue isn't really a problem, other than aesthetics.

clarity of concept

Posted Nov 11, 2014 21:34 UTC (Tue) by javispedro (guest, #83660) [Link] (3 responses)

I think D-Bus has always had problems in the design of their "broker" service. For example the "com.example.interface at /com/example/interface path" pattern is way too common in most D-Bus servers and it doesn't look right to me. I don't understand for example why one needs to create e.g. /timedate1 and /timedate2 instead of being able to create a single /timedate object which implements the multiple versioned interfaces. I suppose it has something to do with (non-namespaced) properties or similar, but it looks like a design problem.

Also, quite common operations such as e.g. "look for any/all objects implementing interface com.example.interface", which are often used in the complex IPC libraries, are missing in core D-Bus. Thus, one is forced to spawn a multitude of registrar-like daemons for every possible interface. Or, alternatively, "abuse" service names like the MPRIS specification does.

clarity of concept

Posted Nov 11, 2014 23:46 UTC (Tue) by HelloWorld (guest, #56129) [Link] (2 responses)

> I don't understand for example why one needs to create ...
One doesn't.

clarity of concept

Posted Nov 12, 2014 0:31 UTC (Wed) by javispedro (guest, #83660) [Link] (1 responses)

That's why I don't understand it :) But on any running system, I have plenty of services doing this with their object paths, e.g. polkit, udisks, nm/mm, nautilus...

clarity of concept

Posted Nov 16, 2014 21:46 UTC (Sun) by HelloWorld (guest, #56129) [Link]

I suspect that that's due to implementation details. This kind of thing is supported well by D-Bus itself, but not by languages like, say, Java.
http://stackoverflow.com/questions/2598009/method-name-co...

Perhaps similar issues led to what you're observing.