1999.06.10 16:56 "Re: Large File Support", by Chris Barker

1. An "standard api" won't prevent you from being compatible with the file using a non-standard api. But it would be a godsend to the folks who find their current implementation deficient and need to plug in another library. I was merely suggesting that a "standard api" be defined alongside the format, and a reference implementaion made. You could then conform to one of "TIFF64" and "T64API", both, or neither.

But this is a big opportunity. With a cleverly designed API (I happen to have one here...) it would be possible to plug other formats in at the back end, leaving the api unchanged. We could then get a little order out of all the chaos.

Of course, a binding for each supported language would be required, but I don't think its as big a deal as you make it out to be. With nearly all OSes supporting shared libraries, these have to be (by their nature) somewhat language independent.

As for being a "TIFF64" (or whatever) producer, you can be *that* with any libraries you care to write. I am suggesting the api bit for those who care to supply libraries (especially public domain ones).

I negelected to mention the important matter of a test suite (*very* important) which you have brought up. It should include a verifier.

--

========================================================================
Barker's law: For every inaction, there is an equal and opposite excuse.

Check out Interlinear's web page at http://www.ilt.com
========================================================================