RE: Critical problem in new format (was: Support for new Plucker features in the Parser.)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bryce Yancey Sent: Saturday, August 07, 2004 11:09 AM To: [EMAIL PROTECTED] Subject: RE: Critical problem in new format (was: Support for new Plucker features in the Parser.) This will, however, make the new format non-backwards compatible. Bummer. If it's not possible to make these changes completely backward compatible, do we want to consider changing the plucker format version number (currently 2)? That way old readers would presumably report the book as incompatible rather than corrupt...which would be a little less confusing to end users. I was thinking of something like that as well. This would be a major change to Plucker, deserving of a major version number increase. And users are more likely to accept major changes in a version upgrade like that. Major changes are *expected*. Simply make it as clear as possible up front that older versions of the reader won't be able to read the new documents. As long as new builds of the reader can still read *old* documents you won't have insupperable problems. Yep. If the format must change, it would be good to add some way to better allow for future changes without breaking the format. Hmmm. Stick as much info as possible in the header describing every bit of the document structure, so future extensions basically change some pointers about where in the file things are? __ Dennis ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Critical problem in new format (was: Support for new Plucker features in the Parser.)
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 navigation data (put after the compressed text/image data). One solution would be to add a new field to the header with the size of the compressed data or the offset to the navigation data. This will, however, make the new format non-backwards compatible. It should be quite simple to write a script that could convert documents from the new format to the old format (without the new features), though. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Critical problem in new format (was: Support for new Plucker features in the Parser.)
It should be quite simple to write a script that could convert documents from the new format to the old format (without the new features), though. Would it be possible to make the viewer do this automagically, upon opening an older format document? The problem I see with writing a script to convert the documents, is that we'll be in the mess of cross-platform compatibility issues. Or perhaps an UpdatePlkr.prc that can be launched to do it? Also, the other bit of a problem, is having to convert the documents to the _older_ format. For example, if someone submits a Plucker document to MemoWare or PalmGear in the new format, and someone without the latest viewer tries to read/run it.. A script would be better in the short term, but I think we'll run into all kinds of new bug reports from users who 1.) can't run the script, 2.) don't want to run the script, 3.) complain that Plucker is broken ;) It might even be a good idea to add another field that includes the header size (or offset to the text/image data) to be able to handle future changes without breaking the format. I agree with this, definately. d. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Critical problem in new format (was: Support for new Plucker features in the Parser.)
On Sat, Aug 07, 2004, David A. Desrosiers wrote: Would it be possible to make the viewer do this automagically, upon opening an older format document? Wrong direction ;-) The problem with a non-backwards compatible change to the Plucker format is that only new viewers would be able to read the format. Old viewers would report the Plucker document to be corrupt. The script would be used to change the record header into a format old viewers can handle. New viewers would be able to handle both formats and we could also include an option to convert old documents to the new format. The problem I see with writing a script to convert the documents, is that we'll be in the mess of cross-platform compatibility issues. I would write it in perl or python. It's just a matter of changing the header for each record. Also, the other bit of a problem, is having to convert the documents to the _older_ format. The script is first and foremost for those users using a viewer on a different platform, i.e. to make it possible for them to read documents that use the new record format. We can't control when/if viewers on other platforms will support the new format. The Palm viewer we have full control over and can update to the new format (we can even release patched versions of an older release that supports the new format). For example, if someone submits a Plucker document to MemoWare or PalmGear in the new format, and someone without the latest viewer tries to read/run it.. Well, that's the problem I'm trying to solve ;-) A script would be better in the short term, It is intended to be a short term solution... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
RE: Critical problem in new format (was: Support for new Plucker features in the Parser.)
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 navigation data (put after the compressed text/image data). One solution would be to add a new field to the header with the size of the compressed data or the offset to the navigation data. This will, however, make the new format non-backwards compatible. Bummer. If it's not possible to make these changes completely backward compatible, do we want to consider changing the plucker format version number (currently 2)? That way old readers would presumably report the book as incompatible rather than corrupt...which would be a little less confusing to end users. It should be quite simple to write a script that could convert documents from the new format to the old format (without the new features), though. Sounds like a reasonable short-term solution. It might even be a good idea to add another field that includes the header size (or offset to the text/image data) to be able to handle future changes without breaking the format. Yep. If the format must change, it would be good to add some way to better allow for future changes without breaking the format. Comments? Suggestions? /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinf o/plucker-dev ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
