An analysis about a generic desktop application configuration management system

[Avery Pennarun]

On Mon, Apr 11, 2005 at 08:55:44PM -0400, Patrick Patterson wrote:

> On Monday 11 April 2005 20:42, P. Kaluza wrote:
> > So i _suggest_ (as others have before me) to adopt DBUS as the protocol
> > for all client<->first-tier-server. This _is_ negotiagble, but please
> > state your reasons. It is actually an implementation detail - but the
> > one I'd like to see decided really really soon.
>
> Why bother at this point? Let's do like every other standards body before
> us, and define what the protocol looks like, and ignore the transport of
> that protocol - it may be that D-BUS is the right way to go, but there
> could be an argument made for DCOP, and straight up Unix Domain Sockets.
> 
> So let's start working towards the checklist - that's it, that's all -
> when the requirements states "There shall be a server and a client and
> they shall talk with the following semantics", then doing a DBUS, DCOP or
> any other implementation is trivial, and writing bridges between them is
> trivial as well...

There is an argument for defining the transport layer first, even though
it's getting into the design.  That's because it helps decide *what* to
standardize - something people haven't even quite agreed on yet.

It's very clear that people aren't going to agree to a single frontend API;
KDE people want C++, and Gnome people want C.  There's no way to rectify
that problem.  They might agree on a single protocol; KDE people want DCOP,
and Gnome people want D-BUS, but I suspect neither group is as religious
about that issue.  They really could agree on a single backend server to
talk to via that protocol; nobody really cares what that server is, as
long as it doesn't suck in too many extra dependencies (which is an argument
against UniConf).  And I think a *message schema* spec is genuinely possible
to agree on with all parties; it's kind of an embodiment of the
requirements.

For example:

	MESSAGE				RESPONSE

	get(keyname)			get_response(value)
	set(keyname,value)		set_response(bool)
	...				...

Of course, there should be more details, like data types and so on.  But in
order to have any kind of unified system, you have to have a shared set of
interface concepts to talk about.  Then you can embed them into a protocol
and write the shared backend daemon.  Then you can write the frontend API(s)
that talk to that daemon.

But that means we could go through these steps:

 0. gather fundamental requirements (already done, really; read the list,
    read that wiki page).

 1. agree that we need a daemon, based on the requirements.  If we don't,
    stop following these steps, because they're broken :)

 2. agree on the set of messages we need to pass to/from the daemon.
 
 3. agree on the protocol(s) the daemon should speak (presently a battle
    between DCOP and D-BUS, I gather)
    
 4. write the backend daemon(s) that implement this protocol.
 
 5. write the frontend API(s) that talk to the daemon.

Note that since D-BUS and DCOP have such similar APIs, I think we could
actually implement the same set of messages over both.  Of course, that
still leaves some extra work to interlink Gnome and KDE.  But we could save
that for another day.

Have fun,

Avery