AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2016.07.05 09:41 "[Tiff] Proposed API improvements", by Yakov Galka
2016.07.05 14:51 "Re: [Tiff] Proposed API improvements", by Olivier Paquet
2016.07.05 15:41 "Re: [Tiff] Proposed API improvements", by Bob Friesenhahn
2016.07.05 16:14 "Re: [Tiff] Proposed API improvements", by Olivier Paquet
2016.07.05 17:18 "Re: [Tiff] Proposed API improvements", by Bob Friesenhahn
2016.07.05 19:52 "Re: [Tiff] Proposed API improvements", by Olivier Paquet
2016.07.06 14:25 "Re: [Tiff] Proposed API improvements", by Yakov Galka
2016.07.06 14:48 "Re: [Tiff] Proposed API improvements", by Bob Friesenhahn
2016.07.19 13:36 "Re: [Tiff] Proposed API improvements", by Yakov Galka
2016.07.19 14:17 "Re: [Tiff] Proposed API improvements", by Olivier Paquet
2016.07.19 14:41 "Re: [Tiff] Proposed API improvements", by Bob Friesenhahn

2016.07.05 16:14 "Re: [Tiff] Proposed API improvements", by Olivier Paquet

2016-07-05 11:41 GMT-04:00 Bob Friesenhahn <bfriesen@simple.dallas.tx.us>:

when it is introduced. A concern would be that most using applications are already written, existing applications still need to work with many existing libtiff versions, and so the new interface would not be used.

While I agree uptake will likely be very slow and limited, by that argument, we'd never improve anything.

to those functions. There is the possibility of using thread specific data to avoid this approach, but this assumes that the thread which registers the error callbacks is the same as will be later using libtiff functions which need to call this error handler. I have some thread specific data API

A bad assumption to make in my experience. Besides, this doesn't fix the problem with multiple competing error handlers in different parts of a single threaded application. Binding the error handler to a TIFF handle would fix it and requires no knowledge of threads.

Olivier