Received: by whizzer.wpd.sgi.com (/911001.SGI)
	 id AA12772; Tue, 15 Feb 94 00:06:45 GMT
Received: from sgi.sgi.com by whizzer.wpd.sgi.com via SMTP (/911001.SGI)
	for /usr/people/sam/majordomo/wrapper resend -l tiff -h sgi.sgi.com -f tiff-owner -s -m "-oi -odq -om" tiff-list id AA12730; Mon, 14 Feb 94 16:06:29 -0800
Received: from subnet.sub.net by sgi.sgi.com via SMTP (931110.SGI/910110.SGI)
	 id AA26991; Mon, 14 Feb 94 15:20:52 -0800
Received: by subnet.sub.net via suspension id <16061>; Tue, 15 Feb 1994 00:00:37 +0100
Received: from flatlin.ka.sub.org by subnet.sub.net with bsmtp id <16068>; Mon, 14 Feb 1994 23:47:55 +0100
Received: by flatlin.ka.sub.org id <m0pWBQz-0000EAC>; 14 Feb 1994 23:06 +0100
Received: from kroete2.UuCP by bock.freiburg.sub.org (NX5.67d/NX3.0M last modified 31.1.94 by FW )
	id AA12408; Mon, 14 Feb 94 22:58:06 +0100
Received: by kroete2.freiburg.sub.org (Smail3.1.28.1 #4)
	id m0pW15H-0000cWC; Mon, 14 Feb 94 11:03 GMT
Message-Id: <m0pW15H-0000cWC@kroete2.freiburg.sub.org>
From: erik@kroete2.freiburg.sub.org (Erik Corry)
Subject: Error/warning handlers in libtiff
To: tiff@sgi.sgi.com
Date: 	Mon, 14 Feb 1994 12:03:22 +0100
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2644      
Sender: tiff-owner@sgi.sgi.com

> As others have mentioned, there are of course ways to override the
> default action. The real point, though, is that you would like to
> formulate the new way of performing an interface-action in such a way
> that it can be gracefully integrated with the libtiff proper. The reason
> isn't just for other host's sake; if your code remains compatible with the
> public libtiff, then when improvements/new compression schemes (such
> as the long-awaited JPEG-in-TIFF) become part of libtiff you will not
> have to deal with so much grief.

While we are on the subject, there is a fairly simple change to the Tiff
library, which I have not yet had time to do, but which would improve
the usability of the library in applications with several threads.

The libtiff has a generally exemplary clean interface, but...

At the moment, the only way of getting information other than the error
message itself into the error handler is through global variables. For
example the infos allowing the error handler to pop up a window in X 
(application context, parent window, application name for the window
manager bar) must be accessed by the error handler through global variables.
This is generally undesirable and obviously precludes having several
app-contexts. In the application in which I use the libtiff at the
moment, there is a second problem, as the libtiff is called from
signal handlers. (As well as from the User Interface, X-Windows code).
It is very difficult to know what to do about error messages since X
is not callable from a signal handler, and X is also not callable from
a library which in turn uses the libtiff, but is not X-based. It all
becomes very ugly.

My proposed solution would be:

1) To allow the user of the library to give a void pointer as error-handler-
client-data. When the error handler is called, it is given this void
pointer which is cast into a pointer to a structure containing all the
context the error handler needs. This technique, under the name of client_data, 
or closure works very well for X-Windows allowing you to avoid global
variables, with the problems they bring with them.

2) To allow the error handler and closure to be given on a per-tiff basis,
ie as parameters to the 'open' functions. This means storing the values
in the TIFF structure instead of in global variables. For backwards
binary compatibility, the old functions could be adapted to still produce
the expected results.

As I said, I have not yet had time to make these changes. Would they be
integrated into the library if I did?

--
Erik Corry, Skagerrakstr. 2, D-79100 Freiburg, +49 761 406637
erik@kroete2.freiburg.sub.org


