Configuration API

[Sean Middleditch]

On Fri, 2004-04-30 at 07:14, Lars Hallberg wrote:
> Thomas Leonard wrote:
> 
> >On Thu, Apr 29, 2004 at 01:06:23PM -0400, Sean Middleditch wrote:
> >[...]
> >  
> >
> >>This is a good place for specification (which has no need to be codified
> >>in the API) to step in.  I.e., we provide this API and programming
> >>interface for backends.  We also provide a document of "freedesktop.org
> >>approved formats" for storing common data types.  I.e., this
> >>specification might say that "All colors must be stored as hex-encoded
> >><string>s as specified in the following W3C standard..."  We can then
> >>provide names for these formats.
> >>    
> >>
> >
> >That sounds ideal. It should actually make it easier to specify new types,
> >since we just have to add them to the list ("Colours should be #rrggbb")
> >and front ends can add support when they need to, while all backends
> >continue to work fine without changes.
> >  
> >
> Think we need more. Some existing config format store colors in other 
> format. Ther backends have to translate fourth and back to the standard 
> one. It would also be nice with syntax checks on the formats.

The backends would have access to these "format" types as well, and so
they can do whatever they want with them.  If we're talking, say, a date
string (base type string, format date) with a SQL backend, it might be
stored using a DATE column type or something.  The API could of course
have an error code for the set_key function like ECFG_FORMAT_SYNTAX or
something.  The standard would specify the syntax, and apps that don't
follow it might get this error with certain backends.

I don't think the core library itself should do this syntax checking
because the number of special formats we have could get very large, very
quickly.  We want to keep the core library lite.  I'm not convinced
it'll be that big of an issue, either.

It's also possible to write a "debug" backend that layers over any other
backend but provides mandatory syntax checking of special formats so
developers can test their application.

> 
> >Yep. I think people should be able to buy into a shared config system
> >without having to accept our schema language. We should propose a shared
> >one separately (the Config4GNU team will have a lot of ideas here, I'm
> >sure), but it should stand on its own merits.
> >  
> >
> If it is possably to make optional in a clean way, thats good!

No reason it wouldn't be.  The get_schema call might just not return a
schema.  The documentation should still stress the importance of a good
schema, however.  And any schema format developed should be easy to
author.  Over-engineered XML files are something we don't need.  ;-) 
XML does allow us to go back to the multiple layers of difficulty. 
(Just as in my proposal apps can just use core types, or additionally
use the format specifies.)

i.e., a simple schema entry might look something like:

 <schema id="/my/key" type="string" />

Tada.  A more complete schema entry might be something like:

 <schema id="/my/key" type="string" format="date">
   <description lang="en_US">The date of the user's birth.</description>
   <description lang="XX">...</description>
 </schema>

We'd also have special entries for enumerations, ranges, regex checks, 
to provide information to GUI editors, and possible for special "check
registry" tools.  I'm not convinced that every key access should have an
enforced check against these, though it is certainly possible.  It would
provide some robustness...

 <schema type="integer" ...>
   <check>
     <range min="10" max="90" />
   </check>
 </schema>

 <schema type="string" ...>
   <check>
     <enum>
       <option value="all">
         <description>...</description>
       </option>
       <option value="some">
         <description>...</description>
       </option>
     </enum>
   </check>
 </schema>
> 
> /LaH
> 
> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.