[Openicc] Linux CM ideology .. Linux CM proposal

[Graeme Gill]

Chris Murphy wrote:
> 2. It should be able to work for 1000 profiles. If it does, it will work fine for 10
> profiles. The reverse is not true.

Sure, but there is no point putting lots of complexity in to optimize a theoretical
case. In software development it's known as premature optimization.
And in graphics, searching through even a thousand profile names is
not likely to be a noticable portion of memory space or processing time - rendering
is where it's at, since it involve millions of pixels.

> 3. We have a non-database caching mechanism for profiles on Mac OS X, as applications
> are not supposed to go looking for profiles in specific places. Rather they are
> supposed to ask ColorSync to list all available profiles, or list all available
> profiles of class mntr, or list all available profiles of class prtr that are RGB. And
> in the past this database was just an XML plist and it would get corrupted. And then
> they went to some binary thing and it got corrupted less. And now it looks like it's a
> hybrid, I'm not sure what it is but if anyone wants a copy I will send it. I haven't
> had problems with this cache getting corrupted in a while - maybe a couple of years.

Sounds like a lack of locking and/or safe file writing.
As far as corruption is concerned, I'd rather try and fix a human readable
flat file, than a binary database....

> People in busy, complex workflows do not need to be able to see a human readable
> database format so long as it's robust and simply works. The database, even if human
> readable, would be huge and gangly and risky to edit anyway. And in simple workflows
> with few changes, implies users who definitely don't need a human readable database.

I'm not sold on either approach (readable flat file vs. database), I'm just trying
to weight up the pro's and cons. I doubt that either approach has a speed issue.

Graeme Gill.