Not The Unix Way? [LWN.net]

Not The Unix Way?

Posted Jul 6, 2007 11:40 UTC (Fri) by Richard_J_Neill (subscriber, #23093)
In reply to: Not The Unix Way? by MathFox
Parent article: Mandriva adds a semantic layer to the KDE 4 desktop

That makes sense - providing that it isn't a KDE-specific thing. I'd have expected it to be more on the lines of something freedesktop.org would provide. We'd also need a good CLI application to match.

However, I still think that metadata belongs *in* the files, not in a database. So if I move/copy a file, the metadata should stay embedded in it.
How does the semantic layer stuff maintain consistency when you do this?

(Log in to post comments)

Not The Unix Way?

Posted Jul 6, 2007 12:33 UTC (Fri) by MathFox (guest, #6104) [Link]

If the "semantic interface" is simple enough to use in KDE-C++, it shouldn't be too hard to create a GNOME-C adapter for it.

About metadata belonging *in* the files: In what file do you store a relation between files? Furthermore there is the "minor" problem that many file formats don't support metadata of the format required for the semantic layer, it would require tools that can handle "all file formats". And performing a complete file system scan to collect all metadata is a costly operation. I would think about a database that identifies files by hashes of the file contents; such a scheme could work with "off line storage" too.

Not The Unix Way?

Posted Jul 7, 2007 0:33 UTC (Sat) by Richard_J_Neill (subscriber, #23093) [Link]

You're right about the problems. But I think that the semantic database has got to cope gracefully with editing/renaming/moving of the files, even when they are moved off the computer entirely, and the database loses sync.

Because this is such a hard problem to solve, I'd prefer to do without the semantic stuff, rather than sacrifice the ability to use the unix-shell commands (or risk losing the integrity of the database). [inotify may help a bit here].

Lastly, files which don't have metadata are usually simpler formats such as .txt and emails. So the problem isn't that bad. Anyway, we have grep, and locate (so what more could one ask for?!)