I just committed new TIFF tag names to SVN, let me know how they work for you.
The best time to add the new metadata methods is before the 1.0 release, since changing binary compatibility later will be harder. On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi <farr...@wellfleetsoftware.com> wrote: > +1 on having the methods: > > Imaging.getExifMetadata() > Imaging.getIptcMetadata() > Imaging.getXmpMetadata() > > It is is a good idea so one can access metadata-format-specific metadata in > a metadata-format-specific way and handling all special needs of specific > metadata formats. These methods should work on any image resource and throw > something like MissingFeatureException for when a metadata format is not yet > supported for an image format or throw something like an > InvalidRequestException when a metadata format is invalid for a image > format. > > That said, there may still be some value to having a metadata-format netrual > getMetadata() interface along the lines of the patch I submitted. For now, > we could simply log an issue and defer it and insteda focus on your > suggestion above. That would meet my needs just fine. > > Question is do we do these changes after a formal 1.0 release or before? May > be it is better to get stable code under current API out as 1.0 and then > work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are not > backward compatible and are in fact major). Or is it better to do these > changes for the 1.0 release so consumers of the project do not get exposed > to a big API change? > > If we can do the proposed change without a long delay then I suggest we do > it for 1.0. If it means a long delay then I suggest we defer to 2.0. > > Thoughts? > > > > On 07/03/2012 03:58 PM, Damjan Jovanovic wrote: >> >> I've also considered the metadata interfaces we use, and I am not sure >> the current approaches are any good. >> >> Most metadata formats are designed in a way specific to that format, >> eg. some have arbitrary levels of nesting, others have a flat >> structure, etc. But most are designed to be stored in any image >> format. >> >> So instead of a Imaging.getMetadata() method that tries to unify all >> metadata into one common interface - and does so badly, because eg. >> EXIF can have nested subdirectories and this information is lost - >> maybe we should have: >> Imaging.getExifMetadata() >> Imaging.getIptcMetadata() >> Imaging.getXmpMetadata() >> >> Regards >> Damjan >> >> On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi >> <farr...@wellfleetsoftware.com> wrote: >>> >>> Updated proposed patch with following new changes: >>> >>> Add getValue() method to nested class IImageMetadataItem. These return >>> the >>> value of the item as an Object allowing for values of various types to be >>> returned. >>> >>> >>> On 07/03/2012 11:01 AM, Farrukh Najmi wrote: >>> >>> Moving this thread to dev list as it seems to be more appropriate >>> there.... >>> >>> Attached is a patch to the IImageMetadata.java that reflects my revised >>> proposal thinking this through in conjunction with the proposed solution >>> in >>> another thread... >>> >>> Add a getMetadataSpecification() method to IImageMetadata so we can >>> manage >>> the metadata specification that defines the metadata >>> Add getMetadata() to nested class IImageMetadataItem to get back at the >>> parent IImageMetadata instance so we can access the metadata >>> specification >>> information managed from an IImageMetadata instance >>> Add getId(), getName(), getDescription() methods to nested class >>> IImageMetadataItem. These are the key triplet of info about the metadata >>> item that is needed in my experience >>> >>> Of course implementations of these two interfaces would need to also be >>> updated to support the new methods according to proposed semantics. I >>> would >>> be happy to contribute in any way that I can and as requested. >>> >>> Dev team colleagues, please weigh in on the proposal. Thanks for your >>> awesome work to create this project and for considering this proposal. >>> >>> > > -- > Regards, > Farrukh > > Web: http://www.wellfleetsoftware.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
