Implement Properties

[nagy]

This brings initial support for properties. For each registered dbus-object we preimplement the org.freedesktop.DBus.Properties interface.

With this commit, only the Get method is supported. The GetAll method is lacking and signals for property changes are not emitted as well.

More info on DBus properties:

https://dbus.freedesktop.org/doc/dbus-api-design.html#interface-properties

I can work more on extending the properties support if you are interested.

[death]

Hey,

I'm not sure that every dbus object should implement or support this interface.

Maybe it would make more sense to be able to pass a (:class my-dbus-object) option to define-dbus-object.

Then you could define a dbus-properties-mixin class and a my-dbus-object class that inherits from both this mixin class and class dbus-object. The mixin could provide a way to define properties and implement the required dbus methods. The mixin could then be part of the dbus library.

This kind of change would be a bit more ambitious and require some design and exposing some names and protocols to the library's user. Would you like to work on that? If so, I could try and help if you have any questions.

In general, publish.lisp is not so well thought out. You can check the issues where I referred to some of its flaws. Since I'm not using dbus nowadays, I've not worked on it. But I'm hoping someone who uses it would find it worthwhile to look into them.

[nagy]

I'm not sure that every dbus object should implement or support this interface.

I agree with that.

Maybe it would make more sense to be able to pass a (:class my-dbus-object) option to define-dbus-object.

I dont think users should have to come up with arbitrary class names just to be able to use properties, unless of course I am misunderstanding your suggestion. How about, we still implement that interface, but hide it until the user of an object at least sets one property using #'define-dbus-property?

Then you could define a dbus-properties-mixin class and a my-dbus-object class that inherits from both this mixin class and class dbus-object.

Would there be any other use case for such a class inheritance structure?

This kind of change would be a bit more ambitious and require some design and exposing some names and protocols to the library's user.

I had some other suggestions, which I wanted to write down into one issue. However, contrary to what you are suggestion, the theme of my proposals would have been to move more towards standardized common lisp interfaces and therefore expose less to the user, relying on knowledge of the standardized CL apis. Maybe my argumentation from the top would be more clear, once I collect and write those down.

Would you like to work on that? If so, I could try and help if you have any questions. ... . Since I'm not using dbus nowadays, I've not worked on it. But I'm hoping someone who uses it would find it worthwhile to look into them.

Understandable. I have got some of what I wanted to have hackishly working over at my fork. I am interested in properties support, with that, signaling the property changes as well, and introspection, for the time being. But I am willing to give it a proper implementation if we find a way to agree on a strategy.

[death]

My suggestion was to start with thinking about the semantics of associating a user-defined CLOS class with a DBUS object (an instance of that class). Shortcuts can always be added later on, for example a (:mixin dbus-properties-mixin) clause that adds a mixin to a generated class instead of having the user name and define it.

DBUS (the protocol) supports the concept of interfaces. Interfaces can have implementations that may usefully be shared across multiple DBUS objects. Classes can serve as the mechanism to specify the layout and behavior shared between multiple objects. The interface implementations may be defined as mixin classes and associated methods in generic functions. For example, the introspection interface can also be implemented as a mixin class.

The DBUS library should provide both lower-level interfaces and higher-level interfaces. Details of the high-level interfaces should ideally be exposed to the user at carefully chosen juncture points. Think of the meta-object protocol, which tries to balance between the hidden and the exposed.

Hope that helps.