Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-b.b-one.net (mx-b.one.com [91.198.169.49])
	by mail9.b-one.net (Postfix) with ESMTP id 77576400164
	for <info@awaresystems.be>; Fri, 27 Nov 2009 06:49:21 +0100 (CET)
X-Virus-Scanned: by one.com
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=6 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-b.b-one.net (Postfix) with ESMTP id CB08D1A1
	for <info@awaresystems.be>; Fri, 27 Nov 2009 06:49:20 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 8D5431D25F5F6;
	Fri, 27 Nov 2009 00:46:28 -0500 (EST)
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com
	[66.111.4.28])
	by lists.maptools.org (Postfix) with ESMTP id C2ED11D22E53C
	for <tiff@lists.maptools.org>; Fri, 27 Nov 2009 00:41:55 -0500 (EST)
Received: from compute2.internal (compute2.internal [10.202.2.42])
	by gateway1.messagingengine.com (Postfix) with ESMTP id 0BB85C1960
	for <tiff@lists.maptools.org>; Fri, 27 Nov 2009 00:41:50 -0500 (EST)
Received: from heartbeat2.messagingengine.com ([10.202.2.161])
	by compute2.internal (MEProxy); Fri, 27 Nov 2009 00:41:50 -0500
X-Sasl-enc: 8z3HdlEprXsSzNlm458q1maHGNrXo0IFof9c/ifV2HIZ 1259300509
Received: from [192.168.1.125] (c-71-236-65-235.hsd1.pa.comcast.net
	[71.236.65.235])
	by mail.messagingengine.com (Postfix) with ESMTPSA id BE78816B51
	for <tiff@lists.maptools.org>; Fri, 27 Nov 2009 00:41:49 -0500 (EST)
Message-ID: <4B0F6698.3060402@spicenitz.org>
Date: Fri, 27 Nov 2009 00:41:44 -0500
From: Adam Goode <adam@spicenitz.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12
	Thunderbird/3.0b4
MIME-Version: 1.0
To: tiff@lists.maptools.org
X-Enigmail-Version: 0.97a
Subject: [Tiff] v4.0 API feedback
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1625171437=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1625171437==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig613B1F297B56134722FC6FDE"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig613B1F297B56134722FC6FDE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

One thing I would really like to see in libtiff is a fully-reentrant
API. Currently, libtiff cannot be used independently from 2 different
callers in the same memory space. This is primarily in the error and
warning handlers, as well as codec registration.

I would like to start working on new APIs that take additional
parameters for currently static structs. I have not looked into it
fully, but this can be done without breaking compatibility by doing
something like this:

 1. Introduce TIFFGetBuiltinCODECs(), which returns a copy of all
    the built-in codecs. This list can be altered by the user,
    without affecting anything else (it is a private copy). This
    is how new codecs would be registered.
 2. Introduce TIFFOpen2, that takes a codec list as well as warning
    and error callback functions. Rework the code of TIFFOpen to
    implement this.
 3. Change TIFFOpen to just be a tiny function that calls TIFFOpen2
    with the old static codec list and error functions. Now things
    calling the old TIFFOpen will work as expected, but new code
    using TIFFOpen2 can register codecs privately and not worry
    about changing the behavior of other callers. More importantly,
    this now allows different threads to use different codecs and
    error functions.


Any thoughts? I think this is important, and I am willing to find some
time to start hacking on it.



Thanks,

Adam


P.S. There are a few non-API places where the library is non-reentrant,
specifically when doing TIFFGetField on WHITEPOINT and a few others.
This can be fixed without changing anything non-private. I am working on
some patches for these too.


--------------enig613B1F297B56134722FC6FDE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAksPZpwACgkQlenB4PQRJaxRDgCgji8GlX2lnz/p0RkgbZEW4e/3
J6cAn21CBXuEJH6jpkrCH8CZFzBLu6Jn
=pNnZ
-----END PGP SIGNATURE-----

--------------enig613B1F297B56134722FC6FDE--

--===============1625171437==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
--===============1625171437==--
