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

[Ikke]

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

Tell him...