AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1999.06.03 19:48 "Large File Support", by Bruce Forsberg
[...]
1999.06.07 13:03 "Re: Large File Support", by Frank Warmerdam
1999.06.09 03:05 "Re: Large File Support", by Glen
1999.06.09 13:13 "RE: Large File Support", by Ed Grissom
1999.06.10 13:05 "Re: Large File Support", by Chris Hanson
[...]

1999.06.09 03:05 "Re: Large File Support", by Glen

Folks,

Here's my two cents. Being just a _little_ incompatible is just about as bad as being a _lot_ incompatible. Therefore, "in for a penny, in for a pound". Let's just do the whole thing at once, make a completely new header and solve this thing more or less all at once.

A nice way to handle it would be to add a layer to handle TIFF files like a Microsoft "COM" object. The idea is that you query the layer as to what interface (e.g., 64-bit vs. 32-bit) the object (i.e., TIFF file) supports. So a new program with the ability to handle 64-bit integers would ask for the 64-bit interface first, and if the header is an "old" version with 32-bit stuff, than that query fails. The program would then ask if the file supports the 16-bit version, and of course it does. Fine.

If your program only can handle the 32-bit integers, don't even ask for the 64-bit interface. Just ask for the 32-bit. Now, if the file is a "native" 32-bit version, the query will succeed. If it is a newer 64-bit version, then it would fail (unless, *perhaps*, the new layer could scan the header and guarantee that all 64-bit integers could fit in 32 bit.

I think anything we do is apt to be major. At least this would be an elegant way of handling the differences between old and new files and old and new programs / TIFF libraries. Eventually all (yes, *ALL*) programs would have to / should be changed to use the new layer. But at least this would eventually solve the problem.

What do you all think?

P.S. -- Any bets as to when 64 bits will not be enough?