From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan Moringen Newsgroups: gmane.emacs.devel Subject: Re: Inclusion of dbus-proxy Date: Sun, 22 Aug 2010 23:04:56 +0200 Message-ID: <8986_1282511101_ZZh07366e9Yqy.00_1282511096.23884.675.camel@steed.robot-madness> References: <4045_1282428217_ZZh07312bUcyR.00_1282428214.23884.594.camel@steed.robot-madness> <87aaoesjor.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7BIT X-Trace: dough.gmane.org 1282511124 11206 80.91.229.12 (22 Aug 2010 21:05:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 22 Aug 2010 21:05:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 22 23:05:22 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OnHjC-0005cK-PO for ged-emacs-devel@m.gmane.org; Sun, 22 Aug 2010 23:05:19 +0200 Original-Received: from localhost ([127.0.0.1]:59421 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnHjC-0005Ac-2i for ged-emacs-devel@m.gmane.org; Sun, 22 Aug 2010 17:05:18 -0400 Original-Received: from [140.186.70.92] (port=53213 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnHj3-00059B-OT for emacs-devel@gnu.org; Sun, 22 Aug 2010 17:05:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnHj2-0004CY-20 for emacs-devel@gnu.org; Sun, 22 Aug 2010 17:05:09 -0400 Original-Received: from mux1-unibi-smtp.hrz.uni-bielefeld.de ([129.70.204.65]:47805) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnHj1-0004CK-Nc for emacs-devel@gnu.org; Sun, 22 Aug 2010 17:05:08 -0400 Original-Received: from pmxchannel-daemon.mux1-unibi-smtp.hrz.uni-bielefeld.de by mux1-unibi-smtp.hrz.uni-bielefeld.de (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <0L7K00J00NWDQ400@mux1-unibi-smtp.hrz.uni-bielefeld.de> for emacs-devel@gnu.org; Sun, 22 Aug 2010 23:05:04 +0200 (CEST) Original-Received: from [192.168.2.100] ([217.25.161.242]) by mux1-unibi-smtp.hrz.uni-bielefeld.de (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPPSA id <0L7K009Q7NW9Y450@mux1-unibi-smtp.hrz.uni-bielefeld.de>; Sun, 22 Aug 2010 23:04:59 +0200 (CEST) In-reply-to: <87aaoesjor.fsf@gmx.de> X-Mailer: Evolution 2.30.3 X-EnvFrom: jan.moringen@uni-bielefeld.de X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.8.22.205417, pmx7 X-Connecting-IP: 217.25.161.242 X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:129052 Archived-At: 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