If you have seen the CVS sources, you'll see some major features added for a future release:
- notably a better looking and easier meta-data editor
- and parsing/editing support for Ogg (Vorbis-audio, video?) and MPEG4 (AVI, WindowsMedia?, Real?, QuickTime?, DivX?) meta-data formats.
Newer file format parsers may be added. Why not:
- PDF file information (displayed in the file properties dialog in Acrobat)
- ZIP/JAR files with embedded comments or meta-information folder?
- EXE files on Windows (version info)
- Version resources on Mac OS
- RPM or Debian package information for Linux/Unix
- Source signatures (the "@#filename version date" ID string, which is often compiled within the constant string area), very common on Linux/Unix
- ISO CD image information (TOC and description sector)
Some of these formats will be complex to support, and should be developped separately as pluggable JAR files. I wonder if there is already such common meta-data framework for Java with a common API to parse and edit embedded meta-data. If so, this could save lots of development time by LimeWire itself.
Such plugins already exist for Windows explorer or are part of the MacOS standard (resource forks).
Note that MacOS users should be allowed to share their files directly without needing to package them into archives. The absence of resource fork data in downloaded files is a problem; may be Limewire on MacOS should be able to create and integrate a compound format allowing distributing in one auto-packaged file both the data fork and resource fork, which would be expanded automatically to a usable form once the download completes.
Or, may be, extend query hits on Mac OS, so that they can include multiple URNs: one for the data fork, one for the resource fork. On the Windows NTFS filesystem, this exists in the "file streams" support, which is currently used mostly in hidden system files, where extra streams are accessed using a "$" separator between the main filename and the extra stream name.
In Windows Explorer, the filesize displayed ignores the space used by extra streams, and the stream is treated as if it was a separate file associated with the main file (so a NTFS file can appear empty with size=0 in Explorer because its data fork is empty, but have a non-zero stream length; in addition, Windows and OS/2 support out-of-band meta-data stored in a special database)
So I wonder how Java supports these out-of-band streams or meta-data. I did not see any formal API to handle them in Java, without using external JNI services. |