Re: Inclusion of dbus-proxy

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

Hi Michael.

> >> That's more or less how I did understand it. What I recommend is a
> >> description for the user, which does not use eieio terminology. It could
> >> be a barrier for people not familiar with eieio.
> >
> > I committed the following updated explanation which makes fewer
> > references to EIEIO:
> >
> > ;; 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 Emacs Lisp code
> > ;; that mimics the D-Bus interfaces. This code mainly consists of
> > ;; functions which correspond to the D-Bus interface methods, but
> > ;; information about D-Bus properties and signals is also stored.
> > ;; When called, the generated functions augment their arguments with
> > ;; D-Bus type information and call their corresponding D-Bus methods.
> > ;; When these proxy components are created, names are transformed from
> > ;; D-Bus-typical CamelCamel to something-more-lispy. The generated
> > ;; functions and object slots can be used like ordinary Emacs Lisp
> > ;; functions and object slots.
> 
> Sounds OK to me. Together with an instructive example (showing
> introspection data and derived Lisp functions), it shall be sufficient.

I expanded the commentary section to that extent.

> > I think, I addressed all suggestions which do not depend on changes in
> > Emacs itself. The code is available at
> > https://code.launchpad.net/~scymtym/+junk/dbus-proxy
> 
> I try to play with this next days. Unfortunately, I'm short in time (as
> usual), and I'm on the road next week.

Thanks.

Jan