Common-Lisp bindings

[Noah Kantrowitz]

I started work on some for a research project last year. You can download
them at
https://coderanger.net/svn/school/2007/fall/spacefortress/trunk/dbus-lisp/.
You will need CFFI and closer-mop, but both are available via asdf-install.
Look at the test* scripts to see examples.

 

--Noah

 

From: dbus-bounces at lists.freedesktop.org
[mailto:dbus-bounces at lists.freedesktop.org] On Behalf Of Gustavo
Sent: Wednesday, May 28, 2008 10:11 AM
To: DBus Lista de Discussão
Subject: Common-Lisp bindings

 

Hello, everyone,

I program in Common-Lisp and there is no binding to this library, so I
decided to create one! I've already started to create bindings for the
library with some Lisp abstractions, and when I finish I will create a
wrapper to make these bindings look just like it was a built-in Common-Lisp
library! But there are somethings I'd like to talk about before starting
this second step.

First, I would like not to deal with addresses and to give the user the
possibility to disconnect and reconnect, so it seems that the right choice
is use dbus_bus_get_private and setting
dbus_bus_set_exit_on_disconnect(conn, 0), right? I am asking because the
documentation says that the get_private should be avoided because multiple
connections are slow but I probably won't use more than one connection at
the same time, so I guess it has no problems to use this function...

Second, dbus supports many types, but Common-Lisp has much more! Common-Lisp
also supports optional and endless parameters for functions. So these
values:
- hash-tables with compose keys (like lists or so)
- (heterogeneous) lists (which could be confusing with also heterogeneous
arrays)
- symbols and keywords (both are similar enough to be colapsed to the same
type in a protocol like this one)
- object instances and structures (same as before)
- limitless integers
- rationals
- complex numbers
- functions
- pathnames (for portability issues)
(perhaps other things that I don't remember)

I was thinking that a good idea was to distingüish the result of the method
call org.freedesktop.DBus.Introspection.Instrospect for other common-lisps
clients (or whoever requests throw DBus this distinct introspection) and for
other regular programs. 

So, for instance, when sending a list, an array to some regular program it
would be transformed into an array before the transmition, while, for
common-lisp clients, a list would be sent as '(av)' while an array would be
sent as 'av'. A rational could have the signature '(ii)' and a complex
'((vv))' (since a complex accepts two rationals, two integers or two
floats). Endless integers could be sent as strings or arrays but with
different notations than regular strings and arrays.

Is sending diferent introspections and method returns to different clients
ok or does this violate some rule of the protocol? Or maybe this is not a
good practice? Another idea would be to always transmit the same
instrospection and let program deal with it (a program in C, for instance,
would be obligated to transform, by hand, '(av) into 'av', which is ok to me
(C is already confuse anyway) but C or Java programmers might not like to
deal with this resolution.

Third, a protocol extension idea: there could be a header option informing
something like "oh, whenever you see '(av)' you can transform it into 'av'
if you like" (an array of struct of two type signatures), to deal with the
previous issue in a more portable way. Perhaps another field telling which
internal data representation protocol or whatever this message is "encoded"
in. What do you think? This could be a not good idea since the protocol
supports so many types just to not to have to deals with these issues.

Well, this is it. Sorry for the very long message.
Gustavo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20080528/620db0f3/attachment.htm