Common-Lisp bindings

[Havoc Pennington]

Hi,

On Wed, May 28, 2008 at 1:11 PM, Gustavo <gugamilare at gmail.com> wrote:
> 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...

This is not a good idea if you want to fit into the normal uses of
dbus (Linux and GNOME). A private connection is a waste if you are
using any of the typical open source libraries. The purpose of the
shared connection is to allow all the code modules (such as libs) in
the process to share one connection.

It is *required* that any program running in a user session exit when
the session dbus daemon exits, OR when the X server exits. All
programs running in a user session *must* tie their lifetime to one of
these two or they are broken.

So, if you set_exit_on_disconnect() to false, you should probably find
some other way to encourage your API users to get this right. Both
libdbus and libX11 default to disconnect when the connection is lost
because that is the correct behavior if the program has not done
anything special to handle the disconnect.

> Second, dbus supports many types, but Common-Lisp has much more!

The general idea of dbus is interoperability, i.e. allowing various
unrelated programs to talk to each other. So, if you're using dbus in
its "intended" way, using language-specific types basically defeats
the purpose.

If you're using dbus just for some custom purpose, it's a different
story of course. You are free to pass whatever you want... you could
for example pass a lisp type signature as the first arg to all
methods, or you could make all messages have byte array args over
dbus, and just use some native lisp serialization format.

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

I would not advise having the same interface show up in two ways
(among other things, you don't know who is calling Introspect or
ultimately using the data from it).

If you want a lisp-specific version of each interface, I would suggest
just creating a separate interface on the dbus level. On the language
binding level, you might automatically choose the "lisp enhanced"
version of the interface.

For example you might for each lisp object, say there is an interface
org.gnome.TextEditor. You might report in introspection both:
 org.gnome.TextEditor
 yourdomain.Lisp.org.gnome.TextEditor

And lisp clients would automatically use the second one, while other
clients would use the first. As long as users of your binding don't
see this (keep it behind the scenes) it should be nice.

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

You can already add custom annotations to the introspection data, that
could be a nice approach here.

Havoc