[Openicc] GSoC 2013 preparations

[Kai-Uwe Behrmann]

Am 19.03.2013 01:33, schrieb Graeme Gill:
> Richard Hughes wrote:
>> * yajl isn't a standard dep on most systems
>> * JSON isn't a database

> ucmm has historical precedence over whatever colord does. In addition,

After you suggested ucmm several times, we repeatedly showed that we 
build upon it's basics, last but not least during the last CM hackfest 
in Brno. We rely on that.

> I went to some trouble to pick standard and appropriate technologies,
> and make them available in a form that would invite others
> to build on them. I could have invented a new configuration
> format (say, like udev has done), and just coded it all
> in the most expedient way for my use, but instead I chose JSON
> as more concise, readable and appropriate than (say) XML.
> I documented the schema, and made available a library
> that took care of all the hard work under a free use licence.

We have some code on SF, which takes essential code parts from ucmm for 
building a configuration system.
http://openicc.git.sourceforge.net/git/gitweb.cgi?p=openicc/openicc;a=shortlog
Here is some glue on how it shall work:
http://www.oyranos.org/wiki/index.php?title=OpenICC_Configuration_0.1

>> There would have to be a very compelling reason for colord to switch
>> away from the sqlite database we have now. In Fedora we turn off the
>
> See above. colord is the newcomer. Having played with sqlite some
> more since the last discussion on this topic, I'm more comfortable
> with the idea of adopting it (my main reservation being the
> binary nature of it - the difficulty in examining and
> editing it - shades of MSWin's registry, without a built in regedit
> tool), and I do like the way it takes care of the locking issues, but
> the problem is really one of "if it ain't broke, don't fix it". It
> needs to be easy to change over to it. And at the database
> level it needs to be system independent, ie. just an sqlite file,
> no implied dbus etc.

We successfully collaborate through the above linked JSON format in 
various projects. JSON support is differently implemented and deployed 
by those open source CMS projects. That all makes JSON already a part of 
our history. That all is only a small step away from ucmm.

> So three questions I have are:
>
> * Is the schema documented somewhere ?
> * Is there a process for making changes to the schema in
>    a collaborative manner (ie. an RFC like process) ?
> * Is there a library built over sqlite and available under a free
>    use license (ie. MIT/BSD) to make it dead easy to read and write the
>    information progromatically ?

The need for a external library code has proven to be a show stopper for 
collaboration. That is the lesson learned by colord joining the Linux 
platform IMO. Comming now with a very new SQlite scheme would impose a 
useless burden on already collaborating projects.

>> Just deciding on something as simple as the primary
>> keys for storage has traditionally been impossible between oyranos and
>> colord and so I think this item should be removed from the wiki.
>
> That's a bit of a show stopper problem then.

The items discussed during LGM in Vienna are still on the table for 
Oyranos. Even though not all ideas match easily because of attitudes 
each project brings in on its own. But the keys are not so much my 
concern. Missed modularity is much more a limiting factor.

The here discussed project is one important step to overcome 
philosophical and practical differences and provide a scalable common 
denominator, which each project can extent for it's own fun.

kind regards
Kai-Uwe