Metadata is not very well supported right now, and where it is supported, it is a string format, e.g. for the MSPReader. A string format is okay for a toString while debugging, but is not very flexible for consuming applications, and some formats have useful metadata that an application might want to know about.
A map of key-value pairs seems like the logical structure for accessing metadata in a cross-format-friendly way. This should be added in the relatively near future, and support added to various formats.
A couple standing questions include if all fields should be added to the metadata, or only key ones, and if an attempt should be made to standardize names of fields across formats. My current thinking:
- Ideally, include all fields, but only if applicable to the version of the file. E.g. Windows 2 bitmaps won't report metadata that only applies to Windows 4 bitmaps.
- The benefits of standardization, where possible, probably outweighs the downsides. I expect there to still be a fair amount of format-specific metadata, though, and making documentation about what fields mean may aid considerably in making the metadata useful. I know I've had my eyes glaze over looking at metadata in various applications in the past.
- To that point, perhaps it is not a bad idea to make the getMetadata method configurable so it can take a set of metadata fields the user is interested in, and only return those - and then to provide some default sets. For a general end user application, half a dozen to three quarters of a dozen fields may be all they care about, whereas an expert user may want all available fields.