[Kdenlive-devel] How to handle support for old file format versions reliably
Mads Bondo Dydensborg
mads at dydensborg.dk
Sat Nov 22 15:48:06 UTC 2008
Hi there
In .kdenlive project files, the kdenlive_doc section is marked with a version.
Is it correctly understood, that
Kdenlive 0.5 used project file version (pfv) 0.6
Kdenlive 0.6 used project file version (pfv) 0.7
Kdenlive 0.7 uses project file version (pfv) 0.8
I think the support for pfv 0.6 is tolerable. There is absolutely no support
for handling pfv 0.7 in a way that is different from 0.8
IMHO, we need to make absolutely sure that we can support our old file formats
from now on, that is, we do not break support for pfv 0.8 in any future
version (ok, in 3-4 years, perhaps the situation is different, but you get my
point).
The current method of supporting old file versions is implemented in the
KdenliveDoc class. Upon reading a file, it matches its version against 0.8
(by comparing a double/float using == btw, which is always dangerous). If
its != 0.8 it calls convertDocument. This matches against 0.7 and gives up,
then against 0.6 and converts from 0.6 to 0.8 if doc is 0.6.
I think we should redesign the flow to always call convertDocument. In convert
document, we should first test against the older version, then repeatedly
convert them up. We should also handle too-new versions. So, convertDocument
would right now be changed to do
0.6 => 0.8
0.7 => 0.8 (I'll try to write this)
0.8 => nothing
> 0.8 => error/warning:file format too new
In the future it would be something like this, given two additional pfv
versions, 0.8.1 and 0.9:
0.6 => 0.8
0.7 => 0.8 (I'll try to write this)
0.8 => 0.8.1
0.8.1 => 0.9
0.9 => nothing
> 0.9 => error/warning: file format too new
This would mean, that for any changes to the way the project file is layed
out/constructed, we step the pfv number, and then only have to write a
conversion routine for exactly the just implemented change. Of course, this
requires that changes can always be made from an older to a newer format, but
I am pretty sure, that that is the case.
The convertDocument should probably also indicate to the caller if the version
actually changed, and allow the GUI to ask something like: "You have loaded a
project saved in an older version of Kdenlives file format. The project has
been succesfully converted to the new format. Would you like to write your
project to a new file, or overwrite the old one". I am not sure this is
strictly needed though, but perhaps it will save the day when we at some
point introduces a bug in the conversion routines, or when somebody loads and
edits a project in a new version of kdenlive, then discovers that it can no
longer be loaded in an older version of kdenlive.
See also this issue: http://www.kdenlive.org/mantis/view.php?id=229
Your comments are much appreciated. I don't mind reorganizing the
convertDocument function and KdenliveDoc class, if you think this is the
right approach.
Regards
Mads
P.S. And of course I will create an issue for this - just need some comments
first :-)
--
Mads Bondo Dydensborg mads at dydensborg.dk http://www.madsdydensborg.dk/
They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
- Ben Franklin, Historical Review of Pennsylvania, 1759
More information about the Kdenlive
mailing list