Proposal and RFC: Introducing DAL, the "Desktop Abstraction Layer"
eikke at eikke.com
Thu Jan 13 17:04:53 EET 2005
On Thu, 2005-01-13 at 10:00 -0500, John (J5) Palmieri wrote:
> On Thu, 2005-01-13 at 09:31, Ikke wrote:
> > > > ...
> > > I don't know if DAL is the right name for it but it seems like a worthy
> > > goal. I would think the major goal of a project like this would be to
> > > identify common integration points and define a spec that defines a set
> > > of standard interfaces (signals and methods) classes of applications
> > > should implement. Perhaps the Common Desktop Interface would describe
> > > it better.
> > >
> > > --
> > > J5
> > Hi,
> > thanks for your reply.
> > As far as I understand you're proposing an application should send out
> > events/information/... using some strict well-known interface. I was
> > rather thinking of some other method:
> > application -> (some IPC method: Unix socket, DBUS,...) -> DAL daemon ->
> > (DBUS session bus) -> Listening applications.
> > Like this a developer of (e.g.) XMMS is not forced to get DBUS in his
> > software, he should just deliver a plugin for DAL able to listen on the
> > existing socket and pass a struct to the DAL core, which in turn
> > generates and broadcasts some DBUS message. In this way it's far less
> > intrusive in the code of existing applications. I'm particularly
> > thinking of KDE applications (where DBUS isn't very "common" yet
> > afaik?), or Evolution 2.1 series which have DBUS support etc. They still
> > can use the IPC method they're used to, which also implies applications
> > that use this existing method will still work.
> > Its more like HAL: one central daemon (session-wide here) that takes
> > information from several "agents" (plugins that know how to listen to
> > specific events of specific applications) and sends out DBUS messages
> > representing these events using some well-sprcified interface.
> > If you'd want the application sending out events itself, it'll limit the
> > possibilities. As an example, the xscreensaver developer won't ever be
> > willing to add such a feature , and listening for XEvents isn't
> > really "easy to do" for most desktop apps. Which is where DAL could be
> > usefull: one place that listens to information, and broadcasts it to
> > everyone who is interested.
> > Regarding the name: DAL is just a "working title", a better name can be
> > found :-)
> > Regards, Ikke
> >  http://blog.eikke.com/index.php/ikke/2005/01/09/p66
> Why the extra level of indirection? D-BUS is there to be a secure cross
> platform communications channel. There is really no reason to abstract
> it. If people have political objections to D-BUS then you have already
> lost the desktop integration wars. D-BUS should not be feared. It
> should be the center of any strategy to integrate the desktop and that
> message should be clear to all application developers. Over engineering
> a solution will cause more problems than it solves and just cause
> confusion. This is exactly what D-BUS was created to do; make Desktop
> integration a piece of cake and do it across desktop platforms. Having
> a spec of interfaces that everyone agrees on, while not as glamorous as
> writing code, would go a lot further in getting the desktop integrated.
More information about the xdg