Proposal and RFC: Introducing DAL, the "Desktop Abstraction Layer"

[John (J5) Palmieri]

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 [1], 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
> 
> 
> [1] 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.

--
J5