IRC discussion on i18n, xml/utf8, and 1.8->2.0 data migration issues

[Derek Atkins]

Chris Shoemaker <c.shoemaker at cox.net> writes:

>   I have some comments/proposals that are related to the 1.8<->2.0
> compatibility issue and slightly related to the encoding issues.  So,
> I'll just jump into this thread.
>
>   GnuCash 1.8 is pretty forward-incompatible, in the sense that it's
> not easy to keep the format backward-compatible.  Aside from
> encodings, it just bombs on unrecognized xml elements.  :(

So was 1.6..  New-in-1.8 features would cause your data file to become
unreadable in 1.6.

>   To solve thing for the future, I propose that we let 2.0 at least
> _try_ to continue reading a file that contains unknown elements.  That
> way, if we're smart about how we extend the format, it will be
> backward compatible.

You can read them, but then what?  You would need to /remember/ them
somehow so you could put them back into the data file.. . Otherwise
you just corrupt the data going back.

Also, what happens when an unrecognized tag really has some core
meaning about the object.  For example, let's say that there weren't
a void flag in transactions, but in the next version we implement
transaction voiding -- if you go back in time you lose the semantic
meaning of the flag, or WORSE, destroy that flag.

It's HARD to do this..  Unless we kept the data in the DOM tree and
modified it in-place it would be REALLY HARD to not lose data when we
go back and then forward again.

>   Unfortunately, that doesn't help for 1.8.  For that, I propose a
> "save-as" or "Export" option that will be _sure_ to save a file that
> can be opened with 1.8.  For 1.8 compatibility that file would have to
> drop new features (e.g. no budgets), and if there turns out to be an
> encoding incompatibilty, it can also handle that.

Nah, I don't think it's an issue.  We didn't get a significant amount
of crying from 1.6->1.8 about data files..  I don't think we'll get
much on 1.8->2.0 either.

>   Note: 2.0 datafiles are mostly 1.8-compatible, but this option would
> have to _always_ work.

I just don't think this is a good idea for the above reasoning.

> -chris

-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