Conclusions and a compact list of requirements for deconf-spec

[Philip Van Hoof]

On Sat, 2005-12-10 at 15:31 +0100, Christian Neumair wrote:
> On Sa, 2005-12-10 at 12:44 +0100, Philip Van Hoof wrote:
> > 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
> 
> Thanks for all your efforts!
> 
> I'd like to give you some short feedback.
> 
> You restrict the key path characters to a subset of ASCII, but say that
> the basenames of keys may consist of "All characters with exception of
> the slash and the space". The technical limitations of characters should
> be considered also, i.e. either impose ASCII, or UTF-8-encoding.

Right, the idea is of course to impose ASCII or UTF-8. Feel free to
propose a diff which fixes this (but, again, I marked your E-mail as
important and will certainly look at it when I get back to working on
the proposed specification)

> In "Preference naming conventions", you capitalize "Boolean" but not the
> other types in the ul examples.

Feel free to fix :)

> I'd also like to point out that we need a build infrastructure suitable
> for extracting translations and putting them into the generated
> localized dtds, plus an installation routine. I wonder whether patching
> intltool is enough, or whether we need any further special means for
> ensuring that all the free software players can easily generate
> translations.

Correct. I haven't yet specified an installation routine. I did,
however, specified a schema installation location. One problem with
specifying an installation routine is that this might be platform
dependent.

My plans (for deconf-desk) where to create a library "schemastore" that
can store, alter and give schema's on request. The library nor a service
would get extra privileges. So whether or not getting, storing/altering
succeeds depends on underlying operating system privileges (so the
library can throw errors).

But such a libtool patch should then, of course, utilise the routines in
that library (perhaps by building a little installer tool).

And depending on the build-target could such a library be adapted to the
platform dependencies (and the libtool patch wouldn't have to care about
it). And also would it be possible to create bindings for installer
softwares that are popular on certain platforms (Windows). Don't forget
that also this platform is becoming a popular target platform for many
of the free desktop/software warriors softwares.

Don't underestimate it.


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