Re: Inclusion of dbus-proxy

[Michael Albinus <michael.albinus@gmx.de>]

Jan Moringen <jan.moringen@uni-bielefeld.de> writes:

> Hi,

Hi Jan,

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

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

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

> + dbus-introspection.el

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

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

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

> + The unit tests use ert which is also not currently included in Emacs

Maybe you cam move the unit tests to another package?

> + The use of the cl library may or may not be acceptable

You load it only during byte-compilation. That's OK I believe.

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

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

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

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

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

Best regards, Michael.