Regarding the export of metadata, I do agree that LimeWire should have an option to import/export meta data into separate files (possibly with individual files sharing the same name and location as the annotated file, but with an extra extension.
On Windows NTFS, a new filename with an extra extension would not even be necessary with ADS (alternate data stream), so that the meta-data are always kept along with the file even if it is moved to another location or to another NTFS filesystem). But unfortunately, Java currently has no support to reads/write of ADS files.
On MacOS(X), there are "equivalent" resource forks, but they are considered part of the file. When resource forks are moved to non MacOS filesystems, they are stored in a file placed in a specially named subdirectory. (But if you look at these filesystems on other OSes, you may forget to move the resource forks along with the normal data forks of the file, so this is not a good option.
For me the simplest would be for LimeWire to recognize and import/export meta data within small plain-text properties files with the extra ".meta" filename extension.
A good solution is when meta-data can be incorporated within the datafile: this is what happens with "tagged" .MP3 files. Unfortunately, this modies the data file content, so this only works well when the meta-data is mostly unmutable.
The best solution will come when filesystems will become relational instead of stupidly hierarchical only (a relational filesystem was initially scheduled for Windows Longhorn, but I don't know if this has been delayed again; there's still no equivalent in Linux and MacOSX, and relational filesystems only exist as extensions of large classical RDBMS like Oracle).
The Windows XP filesystem looks like a small introduction by summary support of the "object" filesystem which offers several limited but navigatable views of the same set of files. But this is only an Explorer feature, and not part of the system kernel which still needs hierarchical names, and offers no real service to allow finding supplementary relations between "file" objects and "metadata" objects (like most other existing filesystems, it only offers the "contains" relation between a "container", in a special file named directory, and "file" objects, and not even the reverse relation also not supported on Unix and Mac filesystems). |