clarity of concept [LWN.net]

clarity of concept

Posted Nov 12, 2014 11:08 UTC (Wed) by ceplm (subscriber, #41334)
In reply to: clarity of concept by nybble41
Parent article: Kdbus meets linux-kernel

Which is exactly what I was trying to say: WTF we need any interfaces here at all. Why cannot I have (adjusted to your exmaple):

> import dbus
>
> dbus.SessionBus().get_object('org.freedesktop.timedate1').SetTimezone('Europe/Berlin')

And of course, I would hope for some more Pythonic binding, so it would be more like.

> dbus.SessionBus.get_object('org.freedesktop.timedate1').SetTimezone('Europe/Berlin')

or perhaps

> dbus.SessionBus['org.freedesktop.timedate1'].SetTimezone('Europe/Berlin')

Why do I have to bother with interfaces at all?

Matěj

to post comments

clarity of concept

Posted Nov 12, 2014 12:22 UTC (Wed) by mchapman (subscriber, #66589) [Link]

> Why do I have to bother with interfaces at all?

It's unclear whether your question is "why do I have to specify an interface" or "why does D-Bus have interfaces at all".

The first problem is, of course, just an artefact of the library you're using. You could have a D-Bus library that somehow determined what interface you wanted automatically, for instance.

As for why D-Bus has interfaces at all, the way I understand it is that it provides an additional degree of modularity. A good example of their use is the systemd D-Bus API [1]. All systemd units can be manipulated via D-Bus objects. There are features that are common to all systemd units, but there are also features that are specific to each systemd unit type. So a D-Bus object for a "service" unit, for instance, implements both the org.freedesktop.systemd1.Unit and org.freedesktop.systemd1.Service interfaces, the D-Bus object for a "socket" unit implements both the org.freedesktop.systemd1.Unit and org.freedesktop.systemd1.Socket interfaces, and so on for each of the other systemd unit types.

Now it would certainly be possible to munge all the methods and properties for Unit into each of Service, Socket, Timer, etc.... but then what about the methods and properties that are independent of systemd? Should they be merged as well? Most (or is it all?) D-Bus objects implement the org.freedesktop.DBus.Introspectable interface, for instance.

Interfaces are fundamentally just a namespacing mechanism -- you can have the same method name in two different interfaces implemented by the one object, but namespacing allow sets of methods and properties to be mixed and matched in different ways.

[1] http://www.freedesktop.org/wiki/Software/systemd/dbus/

clarity of concept

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

> Which is exactly what I was trying to say: WTF we need any interfaces here at all.
Because that allows an object to implement multiple interfaces that contain methods of the same name but with different semantics.

There's an interesting blog post that explains why this is important:
http://existentialtype.wordpress.com/2011/04/16/modules-m...

clarity of concept

Posted Nov 17, 2014 7:16 UTC (Mon) by ceplm (subscriber, #41334) [Link] (2 responses)

I was missing a word in my rant: why we need MANDATORY interfaces? Surely they could be optional, and for large objects they could be essential (although, it could be argued that too big objects are a design bug), but why should the time zone setting object (with just a few methods) should have multiple interfaces.

clarity of concept

Posted Nov 17, 2014 11:24 UTC (Mon) by mchapman (subscriber, #66589) [Link] (1 responses)

> I was missing a word in my rant: why we need MANDATORY interfaces?

Please see my earlier post. All D-Bus objects can -- and in my experience, usually do -- implement methods and properties from multiple interfaces. Now it may be perfectly logical to have a "default" interface per object which handles unqualified names, but that seems like it's best just handled by your client library. If your client library doesn't make this easy for you, use a different one.

Anyway, this discussion is pretty moot. The D-Bus specification [1] has been around for over a decade, and although it may have its warts it works well enough most of the time. You can argue that it's wrong, but it's not going to change the fact that it already exists.

[1] http://dbus.freedesktop.org/doc/dbus-specification.html

clarity of concept

Posted Nov 17, 2014 21:37 UTC (Mon) by ceplm (subscriber, #41334) [Link]

First, of course, this discussion is completely moot, I don’t expect anything to change. However, I don’t think it is useless to discuss completely theoretical questions. Actually, I really do enjoy, that I could finally express my thoughts and doubts about the API.

Second, argument “API sucks, but it could be meliorated by library” is in my opinion just that, an admission that API sucks.