AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2005.03.17 03:42 "[Tiff] libtiff and EXIF", by Ron
2005.03.17 03:53 "Re: [Tiff] libtiff and EXIF", by Bob Friesenhahn
2005.03.17 05:15 "Re: [Tiff] libtiff and EXIF", by Ron
2005.03.17 06:00 "Re: [Tiff] libtiff and EXIF", by Joris Van Damme
2005.03.17 06:21 "Re: [Tiff] libtiff and EXIF", by Joris Van Damme
2005.03.17 16:43 "Re: [Tiff] libtiff and EXIF", by Ron
2005.03.17 17:21 "Re: [Tiff] libtiff and EXIF", by Joris Van Damme
2005.03.17 18:57 "Re: [Tiff] libtiff and EXIF", by Ron
2005.03.17 16:00 "[Tiff] [PATCH] libtiff and EXIF", by Ron
2005.03.17 16:55 "RE: [Tiff] [PATCH] libtiff and EXIF", by Vadim Sukhomlinov
2005.03.18 11:39 "Re: [Tiff] [PATCH] libtiff and EXIF", by Andrey Kiselev

2005.03.17 16:43 "Re: [Tiff] libtiff and EXIF", by Ron

Hi Joris,

Perhaps this can be a task for libtiff 4.0.

I'm not a C coder, so what the heck do I know,

don't let those C guys go getting airs on you... now us C++ coders...
:-)

but I still stand by what I suggested way back in http://www.asmail.be/msg0054569097.html

Yes, I saw that. What surprised me more was that it was the only discussion that I found on the subject, which was why I asked.

and subsequent. I feel this would *NOT* have to break current call protocols.

It doesn't _have_ to, cf. the patch I just posted, but if we abstract out a generic IFD parser its going to start looking attractive for maintenance and other reasons. We might not even need to break source compatibility, but if we start moving fields about in structures then binary compatibility will be broken. (ABI = application binary interface)

People won't need to change their code, but distributors of binaries will need to recompile all their apps to use the new libtiff shared lib.

I suggest:

I'm not sure I follow on this, the ExifIFD tag is registered (or at least published in a widely accepted standard, which is good enough for me if not adobe ;-) so we already know this is its intent.

or what you mean here, though I always like generating things that otherwise need to be typed.

What do we get from this that we don't already have from the ability to call TIFFMergeFieldInfo, without needing to enumerate the tag sets it may be called with?

Yes, that is more or less what I have done. The real 'breakage' I was referring to comes from the fact that the 'struct TIFF' contains a lot of stuff that is tiff specific, yet we must still use it for these generic IFD's. If we break it into common and tiff specific parts, we also break binary compatibility, even if all the field names and calling conventions remain the same.

My question is, is the above suggested scheme, that does no break consistency and does not involve code duplication, breaking any applications or any sorts of ABI whatever it is? If not, is it feasable and sufficient?

In the short term, while we look at what people need from this, yes it is probably sufficient. It does involve redundancy and duplication though. We are trying to solve a more general problem than the code was originally written to handle, which usually means ultimately rewriting the original code in terms of the new foundation, even if that is not what you set out intending to do.

But this is precisely why we can delay changes like this until a major new release and make all binary incompatible changes at once. I do like to plan for both long and short term with code like this.

cheers,
Ron


Editor's note: This mail was not originally archived, and has been reconstructed from quotes.