Re: Inclusion of dbus-proxy

[Jan Moringen <jan.moringen@uni-bielefeld.de>]

Hi Michael,

thanks for the feedback.

> > I recently developed dbus-proxy, a framework that makes accessing remote
> > D-Bus objects from Emacs Lisp easier and more transparent than the
> 
> I would call it "proxy D-Bus objects". The objects you are using reside
> on your local host. Accessing D-Bus objects on a remote host is a
> different thing.

The rationale for calling proxies "remote" is that one could also
imagine proxy objects that serve the purpose of exposing (local) Emacs
Lisp objects to the D-Bus.

But you are definitely right in that the current naming scheme is be
misleading. Especially with D-Bus lately gaining some remote
capabilities in the other sense.

> > current `dbus-call-method' mechanism. Since I was encouraged to propose
> > it for inclusion in Emacs, I'm hereby doing so.
> 
> It's a nice idea I really appreciate.

Thanks.

> > Let me start with a simple example of how a typical usage of dbus-proxy
> > looks:
> >
> > (let ((device-kit (dbus-proxy-make-remote-proxy
> >                    :system
> >                    "org.freedesktop.DeviceKit"
> >                    "/org/freedesktop/DeviceKit")))
> >
> >   ;; Retrieve the daemon-version property.
> >   (slot-value device-kit :daemon-version)
> >   (oref device-kit :daemon-version)
> 
> For people not familiar with eieio (like me) it would be helpful to
> explain what's happening here.

When called for the first time on a particular D-Bus object,
`dbus-proxy-make-remote-proxy' looks up the set of interfaces
implemented by the object and dynamically creates EIEIO classes for the
D-Bus interfaces. After that, information about D-Bus properties and
signals are stored in the interface classes and EIEIO methods are
created for D-Bus interfaces methods. The generated methods contain
calls to `dbus-call-method' with some argument processing (based on
method signatures, the argument list is augmented with D-Bus type
designators). When the different proxy components are created, names are
transform from D-Bus-typical CamelCamel to something-more-lispy.

In the example, the following slot value access and function calls just
use the facilities of the proxy object described above to transparently
access D-Bus properties and signals and call D-Bus methods. Note that
the function call syntax for EIEIO methods does not differ from ordinary
function calls.

> > + dbus-introspection.el
> 
> If such a module exists, dbus-introspection-* functions from dbus.el
> could be moved here.

Currently this file contains some accessor functions for D-Bus
introspection data and some signature parsing code. I'm not sure how
this would fit together with dbus.el but I do think these should be
merged. In particular dbus-introspection.el does not depend on
dbus-proxy.el.

> > I am aware of the following problems with respect to the inclusion in
> > Emacs:
> > + Names:
> >   + Generated class names tend to be long and ugly and do not follow 
> >     usual Lisp conventions
> >   + `connect' and `disconnect' may need a `dbus-proxy-' prefix?
> 
> Yes. In general, every Lisp package should use its own namespace.

I will fix this.

> > + The generated class hierarchies only work with the :c3 method 
> >   resolution order which was added to EIEIO upstream a few months ago 
> >   but does not seem to have been merged yet
> 
> This shall be solved before adding your package.

A recent CEDET, or at least EIEIO, version would have to be merged. I
don't know how quickly this can happen, but I can still address the
other issues with dbus-proxy in the meantime.

> > + The unit tests use ert which is also not currently included in Emacs
> 
> Maybe you cam move the unit tests to another package?

Are you suggesting to move the unit test code into a different file or
should the tests be migrated to a different unit test framework?

> > + The use of the cl library may or may not be acceptable
> 
> You load it only during byte-compilation. That's OK I believe.

I did not actually try to byte-compile yet, though ;)

> > ;;; dbus-introspection.el --- Helper functions for D-Bus introspection
> >
> > ;; malformed-signature
> >
> > (intern "malformed-signature")
> 
> What is this good for? The first use of an uninterned symbol adds it to
> the obarray.

It serves the purpose of letting a person reading the code know that he
or she is looking at the "definition" of the condition. I though, if I
just put properties on a symbol one might wonder whether the symbol also
serves some other purpose. Technically it is totally unnecessary, I
guess. Should the call to `intern' be removed then?

> > (defconst dbus-proxy-simple-type-codes
> > (defun dbus-proxy-parse-simple-type (string)
> > (defun dbus-proxy-parse-composite-type (string)
> > (defun dbus-proxy-parse-type-list (string)
> 
> There are already signature parsing functions in dbusbind.c. Maybe we
> could make them available on Lisp level; this could simplify your code.

I wasn't aware of that. I will have a look. Thanks.

> Furthermore, since we are in dbus-introspection.el, the functions shall
> not be prefixed dbus-proxy-*

OK. I wasn't sure, where these functions should be placed. Maybe they
could be in dbus.el and then be called dbus-parse-*?

> > ;;; dbus-proxy.el --- Automatic proxies for remote D-Bus objects
> 
> > ;;; Commentary:
> > ;;
> > ;; Here is a basic example of the intended use:
> > ;;
> > ;; (let ((epiphany (dbus-proxy-make-remote-proxy
> > ;;		    :session
> > ;;		    "org.gnome.Epiphany"
> > ;;		    "/org/gnome/Epiphany")))
> > ;;   (open-bookmarks-editor epiphany 0))
> 
> You could be a little bit more verbose with the example. I suspect, that
> the `dbus-proxy-make-remote-proxy' call declares the function
> `open-bookmarks-editor', which has been retrieved as method from an
> existing interface at "/org/gnome/Epiphany". The following description
> of the algorithm tells it somehow, but it is not obvious.

Basically, yes. `open-bookmarks-editor' is a method on the interface
class that has been generated for "/org/gnome/Epiphany". Calling the
method is like a regular function call. The part about
`dbus-proxy-make-remote-proxy' creating the method is only true when the
interface has not yet been used in any proxy. If it has, classes and
methods do not have to be created a second time.

> Maybe you could also contribute a section to dus.texi.

If that's OK, I would rather wait a little longer so it can turn out how
exactly dbus-proxy may be integrated into the existing D-Bus subsystem
before writing this.

Thanks for the feedback again.

Kind regards,
Jan