Re: Proposal and RFC: DAL, the Desktop Abstraction Layer

[Jamie McCracken <jamiemcc blueyonder co uk>]

Ikke wrote:
> On Thu, 2005-01-13 at 16:03 +0000, Jamie McCracken wrote:
>
> > Ikke wrote:
> >
> > > Hi Gnome desktop hackers,
> > >
> > > This morning I sent an email[1] to the XDG list at freedesktop.org,
> > > explaining some new idea I got and I'd like to hack on.
> > >
> > > I'd like to hear your thoughts on this too, as it won't be very useful
> > > to write something like this if nobody is going to use it.
> > >
> > > Please express your opinion :-)
> >
> > Excellent stuff - I too had been thinking along those lines though mine 
> > was more influenced by application profiles like you get in bluetooth.
> >
> > Profiles define a common api (set of methods and events) such that any 
> > app implementing that profile can manipulate it without knowing anything 
> > else about it (IE theres no need to introspect the methods/events).
> >
> > Profiles come as both public (pre-defined) and private (for propriety 
> > extensions). The idea is that any app can implement any number of 
> > public or private profiles which are defined by some XML based spec. It 
> > would be easy to implement this using DBus as you have suggested.
> >
> > This is great for implementing things like interfacing with an email 
> > app. Its currently not very nice to open an email client and prefill its 
> > contents (with some clients you can pass it as command line parameters 
> > others like Evolution require the use of some nasty corba etc). If there 
> > was an email profile which email clients used then regardless of what 
> > email client was installed I would be able to use it in the same way. 
> > Now if what you are saying is DAL is pretty much the same thing as this 
> > then yes that would be cool to implement.
> >
> >
> > jamie.
> >
> >
> > > Kind regards,
> > >
> > > Ikke                                            http://www.eikke.com
> > >
> > > PS I hope this is the correct list to post an email regarding a topic
> > > like this to. If not, please point me at the right direction.
> > >
> > > [1] http://lists.freedesktop.org/archives/xdg/2005-January/005687.html
>
>
> Currently, it looks like this would be best implemented like as you
> said, bluetooth. We will create a standard way/interface to interact
> certain information, and next to this create libraries that hide the
> technology behind these messages (ie DBUS), so an app can just say
> "announce I received an email", then the library will create a
> DBusMessage following our interface, and send it on the session bus.
> Then in every listening app (which also use our lib) a callback will be
> called. Of course applications can listen on the session bus directly
> too.
> We will have to make several libs of course: a low-level one, one that
> can be easily used by GTK/Glib based apps, one suitde for kdelibs/Qt,...
> so there are no boundaries: if a user wants to use KMail instead of
> Evolution in a Gnome environment (dont ask me why he'd ever do that, but
> well ;)) he should have the same functionality as when using KDE and
> KMail.

Yes Bluetooth's profiles are excellent for this as they allow for 
painless "just works" interoperability but we will need to make a few 
changes. We need to replace its service discovery with an application 
registry so whenever an app is installed that implements a profile it 
gets added to this registry (its basically a lookup table which stores 
all the profiles implemented by the apps) that way if I write an app 
that needs to open an email app I simply have to request a list of apps 
that implement the required profile ID. Unfortunately we cant use GConf 
for this (unless we can persuade KDE otherwise) so you would need to 
implement something here with CLI tools so that it can be called by 
installation scripts.

You will also need to make sure the Dbus implementations have a 
GetProfiles method (to return a list of profile IDs the app supports).

The most work would be in agreeing and publishing the profiles but like 
Bluetooth they can be extendable by simply creating additional profiles 
(version 1 of an email client and version 2 would have different profile 
IDs etc). I like the profile idea very much and its a tried and tested 
method so I do hope you can implement it.


jamie.


> Regards, Ikke