[Openicc] Linux CM ideology .. Linux CM proposal

[Chris Murphy]

On Feb 8, 2011, at 8:23 AM, Richard Hughes wrote:

> On 8 February 2011 13:44, Graeme Gill <graeme at argyllcms.com> wrote:
>> While that would be convenient, I'm not sure the quantity of information
>> is really so large that it is an issue to do a linear search.
>> How many profile can you imagine being installed on a system ?
>> 10 ? 20 ? 100 ? More than 100 is a lot of profiles, because a lot
>> of work needs to go into making each one of them!
> 
> I have 5 registered devices currently in colord, and 55 profiles.

My 2 cents.

1. I could care less about being able to see inside of this database. I just want it to work. I think every file format being human readable as a goal is nonsense. So far, I'm unconvinced this case requires a human readable format. And I think that such formats are more likely to get screwed up when devices are added, removed, added, removed, associations changed, etc. etc. than something that's rather specifically designed for changes, like - I don't know - a real database?

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.

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.

4. In contrast to #1 above, which implies a need for a database: Just with respect to a mechanism for associating device conditions (of which there may be 2 or there may be 30 or more per device, even with a simple combination of driver settings and media) to ICC profiles, I would not get overly carried away with creating a system for this. Why? Well, again, on OS X the PPD uses *cupsICCProfile to define various printing conditions, and profile associations that the manufacturer has defined. ColorSync Utility allows users a way to override these definitions in a more permanent fashion instead of having to choose a particular custom profile every time in the print dialog, rather than the manufacturer specified default. I do not know anyone who uses this mechanism. I do not, mostly because it was hideously unreliable from when it was introduced until maybe 10.4 or 10.5. Actually, I don't even know for sure it's reliable now. Anyway, there is no best practices for using it.

5. As to whether there are default settings only, and users change preferences to customize; or if an admin can change settings and push those as new defaults for existing users as well as new users (who are not admins) is more of a Linux ideology/convention issue. I'm not sure what that is. But if it's anything like Mac OS X used in a major business situation, it would DEFINITELY be preferred for an admin to be able to establish the settings for new and existing users *and* lock those settings. The vast majority of users are not going to be changing these things. If they need to, they would speak with an admin who would then establish/push new settings.

It rarely makes sense that a user A wants to use profile X for the network printer, but user B wants to use profile Y for the same print condition. So I just don't see most regular users making these kinds of changes with any regularity, as one extreme. At the other extreme, my case, I might make a dozen modifications per day as to what profiles are and are not available to applications, which requires that ColorSync updates its cache and then notifies applications of the change. And all of that works well for applications that subscribe to change notification (others have to be relaunched). For those workflows were a lot of change is going on, I think a robust system designed for such changes is necessary.

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.

Chris Murphy