Conclusions and a compact list of requirements for deconf-spec

[Philip Van Hoof]

Hi there,

Today somebody asked an interesting question about it (in private) and
the recently started Portland project is also a good reason why to
repeat some stuff.

I know this mailing list has become a flameable one. I know it'll again
be amusing to see the kids start throwing their unimportant opinions.
Please this time, just ignore them.

Since my holiday starts, chances are high that I might work on some of
my idea's. Including deconf-spec and it's futuristic (most of you guys
call futuristic things "vaporware") implementation.

https://svn.cronos.be/svn/deconf/deconf-spec/trunk/src/deconf-spec.xhtml

I've been talking with three key players in the field of configuration
on the free desktop. A lot people here would be surprised about the
results of those talks. Those talks have happend mainly in private
discussions on E-mail. I've on purpose waited a few months before making
conclusions (they guys most likely already forgotten them). That way I
had the chance to more easily filter away some of my own opinions
(interpreting what they said when having a subjective view on things, is
going to result in believing false truths. This is psychological).

I'll list a few requirements that I remembered and that are written in
my head as "important". 

You might be surprised who mentioned some of them ;-). It might be the
guy that created the configuration infrastructure of your popular
desktop environment or application. And you might be actually using it
when setting a specific configuration in one of the applications that
you are using today and of which you think it's the greatest build since
mankind.


Important consensus
-------------------

Build a specification first (partly done, see above)

Build an implementation that proves the specification (started but
highly unfinished)


Requirements for the schema's
-----------------------------

It must be (or make the system) type safe (this is the main purpose of
schemas, and yes .. this is extremely important);

It must obviously be possible to get and store simple values (strings,
ints, floats, booleans, etcetera);

It must be possible to define homogeneous lists (a list of strings);

It must be possible to define homogeneous combined types (a rectangle, a
color);

It must be possible to define a homogeneous list of homogeneous combined
types (a list of nothing but rectangles or colors);

It must be possible to define complex non-homogeneous types (a font);

It must be possible to define a homogeneous lists of complex
non-homogeneous types (a list of nothing but fonts);

It must not be possible to define non-homogeneous lists of complex
non-homogeneous or combined homogeneous types;

It must be possible to reuse a previously defined key in multiple
schemas;

Each key needs both a short and long description, specified in the
schema;

It must be possible to translate the description field of the key;

Each key needs a default value, except lists which have optional default
values. They must be specified in the schema;

The location of the schemas must be standardized. It must be possible to
store multiple related schemas in one file to reduce the opening and
closing of files;

It must be possible to cache previously opened schemas;

The hierarchy of the keys must be defined by the XML structure of the
schemas (a nested node per key) (suggestion by the current
openoffice.org configuration infrastructure developer);

The hierarchy of the keys must be standardized. Choosing the actual
hierarchy of shareable keys must be driven by a board that decides about
it (for example the location, default and type of the web proxy
setting);

It must be possible to generate proxy code for accessing the
configuration that starts from a specific key-node in the tree. A lot
like what WDSL does for SOAP Web Services (KConfig XT);

The schema must be as humanly readable as possible. Even PLAIN TEXT is
probably not going to be humanly readable enough. It might have to be
carved in stone (people will start flame wars for it not being humanly
readable);

There must exist a standard way of installing schema's for every
possible AND imaginary build/install environment (autotools, nant, ant,
plain Makefile, etcetera)

The desktop process should be allowed to it's own type checking using
the readable schemas.

Requirements for the protocol specification:
--------------------------------------------

It must be possible to access the configuration data with as few
technology dependencies as possible (at this moment the consensus is to
use D-BUS as Inter Process Communication environment);

It must be possible to implement the entire specification on every
imaginable AND possible computing architecture and environment;

The specification must not force a specific way of working or force the
usage of a specific library or technology. At some point during the
discussions I feared that even the usage of the Von Neuman architecture
was to become forbidden;

There must be a way to define transactions. A suggested way was how
transactional procedures are done in the IMAP protocol (usage of a
timestamp).

It must be possible to get notified of changes on a series of by the
application developer chosen keys. This must hook in the mainloop
implementation being used by the application developer (there's
currently many mainloop implementations being used, let's hope Project
Portland reduces the impact of this silly situation);

And finally  ... A rather strange requirement ... (this one is amusing)

... was that the sending of a typed value to let it get stored on a
specific key, while the typed value's type does NOT conform to to
definition of type in the schema of the key, shouldn't HAVE to result in
an error being thrown by the system. It MAY result in an error but it
shouldn't HAVE TO result in an error (note the difference between MAY
and HAVE TO). The result of such an invalid operation is that the
default value gets set (be very open in interpretation here). But in
case the system doesn't implement throwing that error, there wouldn't be
a way to know about the error IF the system DOESN'T implement throwing
that error. Which SHOULDN'T be a requirement specified in the
specification. 

The reason for this is simply that the reading of the schemas SHOULDN'T
HAVE TO happen in the service. It MAY happen in the service but
SHOULDN'T HAVE TO happen in the service. A service that DOESN'T do this,
CAN'T know whether the type is secured or not. But the client library
that receives an invalid type from the service, SHOULDN'T return that to
the developer using the client library. It SHOULD return the default
value in stead.

This one has been a heated debate. I know it's a strange requirement.
Blame the guys that are explaining us that NO SCHEMA HANDLING SHOULD
HAPPEN IN THE SERVICE .. bla bla bla.

Of course this means that the service CAN'T know about types;




-- 
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be