Compression

[Derek Atkins]

Alex Aycinena <alex.aycinena at gmail.com> writes:

> That is not the way I remember the discussion we had several weeks
> ago. Geert was trying to decide whether to implement the credit memo
> feature by using a new xml tag or by using kvp's. The feature table
> relates to how a version of gnucash out in the wild would deal with a
> gnucash file created by a later version that may or may not contain
> kvp's it could not recognize. It was important to get this capability
> out in the installed base so that existing gnucashes could read later
> versions of files that did not use the new feature but would handle
> the case of a file that did use a new feature without inadvertent data
> loss. I believe John implemented that feature.

It's more subtle that that, unfortunately.  An XML version number change
doesn't always help because you can add optional elements.  Here's the
scenario: I update the 'schema' because I'm adding an optional element.
Data objects *without* the element are 100% backwards compatible.  Data
objects *with* the element are non-readable by older versions.  This
means that I need to signal to older versions that there is an error
*only* if the new feature (i.e. new optional element) is used!

If I just change the version number when I update the schema then it
will incorrectly block backwards-compatibility when the feature isn't
used.

Is there an easy way to tell the XML generator to only upgrade the
version number *if* a feature is being used?  E.g., you could have:

<gnc:GncInvoice version="2.0.0">
  ... regular invoice ...
</gnc:GncInvoice>
...
<gnc:GncInvoice version="2.0.1">
  ... credit note ...
</gnc:GncInvoice>

Of course, I don't know what you do if you wind up having multiple,
independent, optional features.  Let's say we change GncInvoice in such
a way that there is both a credit-note optional feature, and some
imaginary Foo feature.  How do I know which 2.0.x relates to which
feature, and how to I signal backwards-compatibility?

And for the record, I implemented the feature table (in trunk -- I
didn't backport it) --- But that's irrelevant to this discussion.

> In the same discussion it was agreed that I would apply my code which
> handles a different situation. If a new xml tag is introduced (which
> Geert was considering but didn't do), gnucash would previously detect
> that and give the user a cryptic message and not load the file. What
> my code does is to simply provide a more useful message in this case
> if, as the new tag is implemented the the gnc-version number is bumped
> up as well. Like the feature table, we want that out in the installed
> base as soon as possible so that new xml-tags that may be implemented
> in the future are handled better by existing deployed gnucashes.

I think it would be better to just key off the unrecognized tag instead
of keying off the version number.  I see many cases where we could add
optional tags but keep compatibility when the tags are not used; I see
fewer cases where we would just want to completely break compatibility
wholesale, regardless of whether a new tag is used (or not).

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available