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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
