Do you prefer embedding the "face" in each mail as metadata instead of keeping a faces db?
I suffer the same thing with mp3 art, embedded in the mp3s. Lots of dup. data plus some players that cannot cope with such decorated mp3 files, including the one in my car :( On 8/20/07, jsnx <[EMAIL PROTECTED]> wrote: > On Aug 17, 5:06 am, [EMAIL PROTECTED] (erik quanstrom) wrote: > > > They already have synthetic file systems built into NT! > > > > i think it's worse thank that. attributes and their ilk essentially > > add methods to a filesystem. > > That's overstatement -- attributes add 'user defined' types to the > filesystem, but that's not the same thing as giving each filesystem > object procedures. It might require polymorphic versions of ls, cat, > &c. -- but probably not, since the extra fields aren't of interest to > them. > > I've seen a lot of criticism of extended attributes on this thread, > but no one has stepped up with a solution that addresses the problem > they solve. Application specific data should go in the file -- we all > agree about that. The file's position in the heirarchy is modeled by > directories, which also carry OS specific metadata -- permissions, > ownership. But where do the oddball intermediaries put their metadata? > For example, where should the desktop environment put file specific > icons or annotations? It can't very well stuff icons into your > doom .wad files. In principle, the desktop could put that stuff in a > mockup of the real file-system hierarchy, but having a /gnome/icons > tree that had to be kept in synchrony with the 'real' filesystem > invites a lot of semantic confusion, as well as an implementation > hassle (broken links, new versions of 'mv', something else?). > > The fathers of Unix saw many things, but who's to say they saw all the > metadata we will ever need? >
