From owner-tiff@olympiakos.com  Fri Nov 24 00:46:21 2000
Received: (from uucp@localhost)
	by smtp02.oce.nl (8.9.3/8.9.3) id AAA28922;
	Fri, 24 Nov 2000 00:46:21 +0100 (MET)
>Received: from smtp01.oce.nl (smtp01.oce.nl [134.188.1.25])
	by smtp05.oce.nl (8.9.0/8.9.0) with ESMTP id AAA24499;
	Fri, 24 Nov 2000 00:39:08 +0100 (MET)
Received: (from uucp@localhost)
	by smtp01.oce.nl (8.10.0/8.10.0) id eANNd8M29210;
	Fri, 24 Nov 2000 00:39:08 +0100 (MET)
Received: from unknown(207.176.88.85) by smtp01.oce.nl via smap (V2.1)
	id xma029201; Fri, 24 Nov 00 00:38:58 +0100
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id SAA15750;
	Thu, 23 Nov 2000 18:35:17 -0500
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Thu, 23 Nov 2000 18:33:44 -0500
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id SAA15729
	for tiff-outgoing; Thu, 23 Nov 2000 18:33:43 -0500
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61])
	by gate7.olympiakos.com (8.9.3/8.9.3) with ESMTP id SAA15726
	for <tiff@olympiakos.com>; Thu, 23 Nov 2000 18:33:33 -0500
Received: from 216-164-250-85.s593.tnt1.atn.pa.dialup.rcn.com ([216.164.250.85] helo=zebu)
	by smtp02.mrf.mail.rcn.net with smtp (Exim 3.16 #5)
	id 13z5rk-0003X2-00 ; Thu, 23 Nov 2000 18:33:21 -0500
Message-ID: <072701c055a6$a8989d40$0101a8c0@zebu>
From: "Alex" <alexcher@pop.mail.rcn.net>
To: "Joris Van Damme" <as.van.damme.joris@planetinternet.be>,
        "TIFF Mailing List" <tiff@olympiakos.com>
References: <20001123200629.1743.qmail@nwcst320.netaddress.usa.net> <3A1D86D6.F2F74E7F@planetinternet.be> <06e201c05598$bf5f7cf0$0101a8c0@zebu> <3A1D9759.8EF5CD6F@planetinternet.be>
Subject: Re: Using libtiff without reading from a file
Date: Thu, 23 Nov 2000 18:39:43 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-tiff@olympiakos.com
Content-Type: text

Joris wrote:
> Alex wrote:
> > TIFFClientOpen() is not perfect.
> > By some reason it takes pointers to all file access functions
> > except Open, i.e a function that takes a file spec and returns
> > a handle. I wish somebody fix this bug in LibTiff interface.
>
> Why is that such a bad thing? In fact, what would be the 'file spec'
if
> you want to read from memory? The one and only complete spec that is
> always suitable is a 32bit 'handle', which you can supply. If you
want
> to work with open files, just open them first. You can assume they
need
> to be opened anyway if LibTiff is to do something on their data, can
you
> not?

TIFFClientOpen() is bad because it is incomplete. It suffices for TIFF
data in core but fails for TIFF files embedded in archives, databases,
resource forks, EPS files and OLE objects. We cannot assume that Open
is trivial in all cases.

There are computers with segmented memory or separate address spaces
for every process. The memory spec may need the process handle besides
the address. Even in the single flat address space one can use ROT13
to convert address to a handle. MS Windows does it all the time to
ensure the separation between the client and system code.

It is possible to open the file outside but it will be closed inside
the library. This design obscures the program workflow and requires
separate error handling for Open and other LibTiff functionws.

BTW, the use of a static variable for the error handler is another
interface problem. The error handler function must be another
parameter
of TIFFClientOpen(). It cannot be set later because the error can
happen
during the call to TIFFClientOpen().




