Proposal and RFC: DAL, the Desktop Abstraction Layer

[Ikke]

> We dont strictly need an abstraction layer. If Dbus does not allow you 
> to query what interfaces a service supports you cant easily implement an 
> abstraction layer anyhow. If it does, why do we need an abstraction layer?
By abstraction layer I meant: a set of interfaces an app should comply
to. Not in code.
If you allow programmers to have "/org/gnome/gedit" and
"/org/kde/kwrite", both objects will expose different methods. If you
define the interface "/org/freedesktop/TextEditor" with some methods an
app willing to comply to the standard must export, and maybe some
optional ones, you don't get that problem, and I can write one
application that uses functionality brought by "a texteditor", where I
don't have to care what texteditor this is (and don't have to know it's
object path, it's special methods,... I just look up the "TextEditor"
part of the standard).

> For us to accept an abstraction layer we need justification for it. You 
> need to tell us what advantage it has over using core Dbus. Bear in mind 
> an abstraction layer is not just extra work for yourself - its also more 
> work for language bindings.
As said before: abstraction layer, not specificly in code. Maybe I chose
the wrong words.

IMHO a code abstraction layer should be written too, which exports
functions like "registerApp" etc, so an app willing to expose itself to
other apps using our standard should not care about the DBUS messages
itself. Calling something like "dal_registerApp(PACKAGE_NAME)" is easier
than something like

DBusConnection conn = dbus_connection_get(DBUS_SESSION_BUS, &error);
//Generate message, blahblahblah
//send signal on the bus, with error handling, blahblahblah
//flush connection

etc

Creating bindings for other languages/platforms can and maybe should be
done too, but thats less necessary if we provide a nice C API already.
Most desktop apps are written in C or C++ anyway nowadays, and using
Swig it is possible to add Python (and maybe C#?) wrappers quite easily.


> > Ikke
> > http://www.eikke.com