Received: by whizzer.wpd.sgi.com (/911001.SGI)
	 id AA09939; Wed, 16 Feb 94 22:39:16 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 AA09923; Wed, 16 Feb 94 14:39:11 -0800
Received: from relay.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI)
	for tiff-relay@whizzer.wpd.sgi.com id AA01515; Wed, 16 Feb 94 14:39:08 -0800
Received: from giraffe.asd.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI)
	for tiff@sgi.sgi.com id AA10048; Wed, 16 Feb 94 14:39:00 -0800
Received: from flake.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI)
	for @relay.sgi.com:erik@kroete2.freiburg.sub.org id AA12983; Wed, 16 Feb 94 14:38:57 -0800
Received: by flake.asd.sgi.com via SMTP (920330.SGI/911001.SGI)
	for @giraffe.asd.sgi.com:tiff@sgi.sgi.com id AA07877; Wed, 16 Feb 94 14:38:56 -0800
Message-Id: <9402162238.AA07877@flake.asd.sgi.com>
To: erik@kroete2.freiburg.sub.org (Erik Corry)
Cc: tiff@sgi.sgi.com
Subject: Re: Error/warning handlers in libtiff 
In-Reply-To: Your message of "Mon, 14 Feb 1994 12:03:22 +0100."
             <m0pW15H-0000cWC@kroete2.freiburg.sub.org> 
Date: Wed, 16 Feb 1994 14:38:56 PST
From: Sam Leffler <sam@flake.asd.sgi.com>
Sender: tiff-owner@sgi.sgi.com

    To:  tiff@sgi.sgi.com
    Subject:  Error/warning handlers in libtiff
    Date: Mon, 14 Feb 1994 12:03:22 +0100
    From:  erik@kroete2.freiburg.sub.org (Erik Corry)

    > 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.

Sounds ok, send me mods to implement it.
    
    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.

Since "open" is synchronous, there's no reason to change its interface.
You can instead setup handlers in separate library calls.  Once again
this sounds ok, though I don't figure to implement it.  Send me mods and
we can discuss getting it integrated into a new version of the library.
    
    As I said, I have not yet had time to make these changes. Would they be
    integrated into the library if I did?

I welcome reasonable changes to the library.  "reasonable" is of course
whatever I think is good :-).  Honestly I'm quite open to improving the
software, but I am not willing to devote huge amounts of time to the
current code or to integrate major modifications w/o a significant
payback.  The library needs a complete rewrite and if/when that is done
it will be recoded in C++.

	Sam





