hobold (no@working.address.sry) on 2/2/09 wrote:
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 2/2/09 wrote:
>---------------------------
>
>[...]
>>I think that people are getting worked up about this problem because it is, in
>>a way, like a political problem.
>
>I have zero prior experience in the matter of extended file attributes. But just
>from listening to the debate, I get the impression that there does not seem to be
>a good terminology for the matter being debated.
>
>People keep using the word "metadata" for, I believe, at least four distinct and
>very different kinds of information. The two bits that distinguish the categories are:
>
>1. hidden/visible
>This isn't really a boolean, because there are degrees of obscurity (e.g. tags
>embedded in a data file can effectively be hidden to users if there exists no application
>that makes them visible). But this criterion is sometimes a feature and sometimes
>an obstacle/a complication. And the decision if something _should_ be visible or
>hidden has a lot of non-technical implications, e.g. security. That's where politics sneaks in.
>
>2. Associated with the contents of the file/with the file as an opaque container
>An example for data associated with the content would be information about composer
>and performer of the music contained in some audio file. An example for data associated
>with just the file as container would be access rights or a date stamp of last backup.
>This is a more sharply defined criterion. (But there is a grey area, e.g. a search
>index hash based on the file contents.)
>
>Overall I see four categories of metadata, each of which has different uses and
>purposes. I am not at all sure that my classification is the right one, but maybe it can be a start.
>
>
>(There is even a third bit, but it is kind of arbitrary: should the metadata travel
>with the file or shouldn't it? I believe that is application dependent, and therefor a matter of taste, so to speak.)



Well, there is certainly a requirement (the desire to attach additional information to a file) that’s real. While it’s a very common requirement (which would suggest OS level support), unfortunately there’s not a real clear definition of what’s required.

There are issues of where to store the data, security issues (user A and B might both have data to store, and probably shouldn’t generally be able to see each others, or necessarily have write access to the target file at all), issues with management, visibility, backup, moving or renaming files, copying files, cleanup and some others.

In a sense this is similar to the conflict Linus has described several times between the hardware and software sides of the business – he’s complained more than once that certain hardware decisions have been made that something is “too hard” in hardware, and they’ve just punted the problem to the software guys, and assumed a magic solution there. Linus is a bit on the other side here - the application folks want the OS feature (because it’s too hard for them to implement), but it’s hard to do in the OS too (not least because it’s still ill defined), and he wants to punt the issue back to them, and let them figure it out – after all, it’s an application issue, no?

But basically all of the solutions so far have significant flaws, which certainly argues against a huge OS implementation, but in many ways leaving it to the applications without any OS help is even worse. Adding to the mess is the fact that no one approach is likely to be generally portable among OSs.

On the flip side, even an OS specific extension may be useful enough. The folks here are probably not going to be all that happy, but I’m thinking of the 99% of users like my mom, who can barely drag a file from one directory in Explorer to another.

Unfortunately it’s also hard to come up with a good middle ground. What features could the OS reasonably supply that would allow applications to solve the problem more effectively. A unique file ID (Apple did that) helps a bit, but alone doesn’t solve many of the problems. You can add notifications to some sort of file system plug-in whenever a file is manipulated (copied, moved, etc.), but then the OS needs to track each application that has associated itself with a file, or let all the plug-ins see all the filesystem changes, which sounds like a great way to horribly slow down your system (and make it unstable). Toss some of that in a higher level, like the UI, and you then immediate leave holes for messing things up with the lower level functions.

In short, the whole area is a mess, and everybody should refuse to deal with it, except, of course, that it’s something that *has* to be dealt with for usability reasons.