| |||||||||||||
Integrated color management with colordIntegrated color management with colordPosted Sep 28, 2011 22:13 UTC (Wed) by quotemstr (subscriber, #45331)Parent article: Integrated color management with colord
Why a daemon and a SQLite database instead of a simple collection of files in a well-known location?
(Log in to post comments)
Integrated color management with colord Posted Sep 29, 2011 0:53 UTC (Thu) by rpkelly (guest, #74224) [Link]
The daemon is presumably so it can be used over D-Bus. As for the choice of SQLite vs. files, I'm not sure.
Integrated color management with colord Posted Sep 29, 2011 7:49 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> The daemon is presumably so it can be used over D-Bus. As for the choice of SQLite vs. files, I'm not sure.
I thought (but may be wrong) that DBus was able to start helper applications in response to queries rather than requiring the helpers to be already running as daemons.
Integrated color management with colord Posted Sep 29, 2011 11:32 UTC (Thu) by rpkelly (guest, #74224) [Link]
Indeed it can. But, it is probably more responsive by starting it and leaving it running as a daemon. Especially since this is a core dependency of GNOME 3.2, one would assume that (in the future) many applications will be making use of it.
Still, I thought the original commenter was suggesting no helper application at all, but instead a shared library. Correct me if I'm wrong, though.
Integrated color management with colord Posted Sep 29, 2011 2:13 UTC (Thu) by malcolmt (guest, #65441) [Link]
An SQLite database *is* a simple collection of one file in a well understood format. Accessible from other programs readily (SQL isn't that hard), including command line access via the relatively small sqlite3 binary. It falls down slightly on the "can't be edited with ed" test for text files, but apart from that it's an ideal choice for things like this. This really introducing some kind of opaque data format and it saves on having to write yet more code to parse text files that can be messed up by random editing (sqlite3 enforces sensible saving format to disk).
There are always going to be people who want text files only removed from their cold dead hands as a data format, but it's 2011 already and we collectively have a few decades of experience in how fragile text file editing can be (and well-known locations tend to be different locations even amongst different Linux distributions). This is a exceedingly minimal extra layer with some quite large benefits. I'm encouraged to see it happening more and more.
Integrated color management with colord Posted Sep 29, 2011 3:12 UTC (Thu) by pabs (subscriber, #43278) [Link]
I've personally considered writing an LD_PRELOAD library for apps that use sqlite just so that non-text files never touch my ~/ and I can continue version control it with git in a meaningful and useful way. I find the way most applications on GNU/Linux distributions treat ~/ as offensive.
Integrated color management with colord Posted Sep 29, 2011 3:32 UTC (Thu) by jimparis (subscriber, #38647) [Link]
To make git happier, maybe you could use a textconv filter to convert sqlite databases into SQL dumps, so at least diffs are meaningful.
Integrated color management with colord Posted Oct 6, 2011 11:37 UTC (Thu) by Wol (guest, #4433) [Link]
The treatment of ~/ - AO b****y L!!!
If system config files go in etc, then personal configs should go in ~/etc or ~/.etc!
Not that mirroring the system setup in ~/ is a good idea, but it's a lot better than the current free-for-all!
Cheers,
Integrated color management with colord Posted Sep 29, 2011 7:50 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> ...and well-known locations tend to be different locations even amongst different Linux distributions...
Surely using DBus for querying the data addresses that.
Integrated color management with colord Posted Sep 29, 2011 12:27 UTC (Thu) by dmk (subscriber, #50141) [Link]
And, not to forget, it also decouples the colormanagment deamon from the applications. If you want to change the implementation of colord to not use sqlite, that is much easier with dbus accessed colord than it would, say, with a shared library.
Integrated color management with colord Posted Oct 4, 2011 10:39 UTC (Tue) by juliank (subscriber, #45896) [Link]
> If you want to change the implementation of colord to not
> use sqlite, that is much easier with dbus accessed colord > than it would, say, with a shared library.
If you designed the library correctly, there would not be any difference in the complexity of changing the format. If you expose sqlite3 types in your library, you did something wrong.
Integrated color management with colord Posted Sep 29, 2011 20:54 UTC (Thu) by kleptog (subscriber, #1183) [Link]
As a bonus they've handled the crash reliability for you, so you don't need to worry about inconsistent or corrupt files...
Integrated color management with colord Posted Oct 5, 2011 7:34 UTC (Wed) by cmccabe (guest, #60281) [Link]
One thing that I think some people are missing is the difficulty of debugging and maintaining complex systems.
I have experience debugging a large software suite with a couple of daemons that communicated using CORBA. I also have debugged the combination of NetworkManager, the desktop manager, wpa_supplicant, and the kernel. In both cases, using remote procedure calls made it a lot harder to figure out what was going on.
If you're using D-Bus or CORBA, you'll need special tools just to observe the messages that are going over the wire. Sure, they're out there, but you'll have to install them and learn them. Then you'll need to get debug versions of all the relevant programs, and make sure that you've restarted all the daemons involved. After that, you'll need some way of correlating log messages between the various programs. If you're lucky, the programs will include timestamps in their log messages that you can correlate with the timestamps in the d-bus output. If you're not, well, you'll have to hack the source.
When you've got asynchronous communication going on, you may very well have race conditions that appear and disappear in a frustrating way.
In contrast, if you were debugging an application that simply read a text file using a shared library, you could probably get pretty far with just "strace <program-name>."
Similarly, UNIX programs should really consider using text files to store configuration. Text files fit in with the rest of the UNIX system-- they can be grepped, rewritten with sed and awk, and so forth. They can be versioned with git or svn, and they take up very little space. If you search on Google, odds are that you will find helpful people who have pasted their text configuration files for you to copy.
However, if the program stores its configuration in, for example, sqlite, most people will not know how to get access to the information in that file, let alone modify it. Yes, in a perfect world, they would be proficient in how to use the SQL language, the application's schema, and the dumper tools, but ours is not a perfect world.
There are some cases where D-Bus and SQL databases are the right solution. But programmers need to stop to think that just because they can, doesn't mean they should.
Integrated color management with colord Posted Oct 6, 2011 13:44 UTC (Thu) by n8willis (editor, #43041) [Link]
It seems like some people are confused about this issue. Colord does not store its configuration in the SQLite db; it stores it in /etc/colord.conf. The db does not store the actual ICC files either; those are in the profile directories mentioned in the article.
The SQLite db stores the *mappings* between devices and the various profiles assigned to them (including the fallback ones). By storing them in a database, the daemon can perform real queries on the various properties of said mappings, in addition to just a trivial (and static) DeviceX:ProfileY.
Nate
Integrated color management with colord Posted Oct 7, 2011 9:21 UTC (Fri) by dgm (subscriber, #49227) [Link]
Very nicely said. It's a pity it's just false...
1. All files are subject to corruption. A text file is "fixable". A database file is not. It's gone. Forever. You cannot even read it.
2. Many times database formats are used for speed. The only problem is that for sequential reading, a text file is far faster than any database. Go ahead, test it.
> but it's 2011 already
So what?
Integrated color management with colord Posted Nov 14, 2011 20:25 UTC (Mon) by job (guest, #670) [Link]
Yes, it's 2011 already. Your computer slurps a hundred lines of text based configuration in a millisecond. You won't even notice. There's absolutely no need to serialize these things in binary any more.
It's both easier and more robust than loading it from an sqlite driver, and you're going to stuff it in your own memory structure anyway.
Integrated color management with colord Posted Sep 29, 2011 11:32 UTC (Thu) by cortana (subscriber, #24596) [Link]
A bunch of text files would have to be read in and parsed when the daemon starts up. A database format eliminates this problem, and SQLite in particular means that it's easy to migrate the on-disk data when the schema changes.
Integrated color management with colord Posted Sep 29, 2011 12:49 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
sorry, the database on-disk format also needs to be read in and parsed. it doesn't store a language specific memory structures in the database.
|
|||||||||||||