[Openicc] Linux CM ideology .. Linux CM proposal
lists at colorremedies.com
Tue Feb 8 14:53:21 PST 2011
On Feb 8, 2011, at 8:41 AM, Graeme Gill wrote:
> Richard Hughes wrote:
>> If editing is a planned feature, then that rules out JSON, XML or any
>> structured markup. No user should be subjected to that.
> There are certain advantages to be able to eyeball configuration,
> particularly when debugging. While it's not likely that users
> will want to edit such things, developers will. Being readable
> (even when JSON or XML) aids transparency, and color management
> needs all the transparency it can get.
OK but how often do SQLite databased self-destruct? How easy/difficult is it to create one that will corrupt? If it works, data goes in, same data comes out. Many things in color management need transparency, but I encoding information isn't necessarily one of them. If the data is reliably going in and coming back out, I think I'm happy both as a user and developer.
And as a database of some sort, which is more likely to have problems eventually. A 1000 profile database based on SQLite, or human readable files at the filesystem level? And are there not tools for debugging databases?
As for cross platform support ICM and ColorSync provide these capabilities, seems like versions of this idea we're talking about for those platforms can just inquire with ColorSync instead of having to invent a solution for that platform. Since profiles can be kept anywhere in the filesystem, there's no consistent location you can depend on searching to find all available profiles. You'd have to inquire with ColorSync anyway.
For ICM, it may be possible to avoid using such a service because I think all profiles are always kept in a single directory and alternates aren't even possible.
More information about the openicc