W dniu 7 kwietnia 2010 19:06 użytkownik Jon Cruz <jon@...18...> napisał:
On Apr 7, 2010, at 9:45 AM, Krzysztof Kosiński wrote:
If you made some XML fix that e.g. changed the way some coordinates are expressed but before a release you suddenly think it doesn't make any sense, you have to bump the document format and add code that reverts the fix, rather than removing the code that executes it. As long as the switch is append-only, and none of the upgrade operations cause data loss, it will work correctly.
Problem is, you now have just introduced all sorts of artificial constraints on your simple solution, and they have a high chance of not working.
Those constraints were part of my solution from the very beginning, I just didn't spell them out explicitly because I thought they are obvious. They have a chance not of "not working" but of "not being followed by developers", since they are primarily on the code in the switch and the way in which it is modified by developers. (There is also a constraint on the content of documents, e.g. that every document is really in the format
No matter how the backwards compatibility system is implemented, you cannot prevent the developers from modifying it in a way that breaks it. However, my system has the considerable advantage that it will always work correctly as long as some simple constraints are followed. For other systems, such correctness-guaranteeing constraints might be very complex or not exist at all.
And, yes, if *any* of the fixups does any sort of change on the data that loses something (e.g. one that was deemed unimportant at one point in time and then later on was found to be significant) then running through all cases *will* result in data loss.
Which is the rationale for the goto hack. You can skip both the data loss step and the best effort recovery, but as I said before if you do this, there's a risk that you'll violate some of the constraints.
So at the very least we will need full documentation on what will and will not be allowed. And someone adding in an experimental feature that gets removed will result in extra cruft being added to files.
Yes, if we decide to implement this, there will be detailed documentation on what you're allowed to do, what is a good idea and what's not. The cruft will only accumulate in the upgrade switch (which is actually its purpose). Any deprecated cruft in the documents themselves can be removed using the upgrade mechanism.
W dniu 7 kwietnia 2010 19:25 użytkownik bulia byak <buliabyak@...400...> napisał:
2010/4/7 Krzysztof Kosiński <tweenk.pl@...400...>:
Consider this:
- I open a 0.47 document with 0.47+devel that has the coords fix
- I save this document
But why do you think it will trigger the upgrade? The upgrade will only happen when your Inkscape is 0.48. The devel series is as good as plain 0.47. Those who want to test the conversion before 0.47 can do this by manually changing version in their tree.
The point of this mechanism is not to make the XML nicer, but to allow us to remove backwards compatibility hacks from the SP tree. Consider this situation: 1. I change the interpretation of guide coordinates in sp-guide.cpp. 2. At the same time, I introduce the XML upgrade which removes the Y axis inversion in XML. 3. Now I have to *downgrade* the document when saving - e.g. add cruft back in!
This means for every XML change, I have to implement the conversion in both directions. It also means that the XML editor does not represent what the content of the saved file will actually look like.
Point 3 might actually be good to have, but in this case we could just leave the choice of the document version up to the user. We would also need unit tests for every operation, to guarantee that each of them really is reversible.
Regards, Krzysztof