How about fixing the new format to be backwards-compatible, instead?
I think compatibility of the format extensions are paramount.
Bill
I found a critical problem in the new format when working on the
viewer implementation. The problem is that the viewer will not be
able to find the
I think that a non-backwards-compatible file format change should be the
very last resort.
Doesn't the compressed data contain a compressed-length field somewhere
that the zlib library uses? If so, the viewer can use that to find the
end of the compressed data.
If not, then only a touch more
On Sun, Aug 08, 2004, Alexander R. Pruss wrote:
Then, if bit 1 is set, the last two bytes of the record
contain the byte offset to navigation data from start of record.
Putting the info at the end of the record is a great idea. Bit 1 is
already used to indicate that navigation data is
