[Pkg-crosswire-devel] Bibledit and Biblememorizer packages
dmsmith555 at yahoo.com
Thu Apr 2 00:58:21 BST 2009
On Apr 1, 2009, at 9:38 AM, Eeli Kaikkonen wrote:
> Quoting DM Smith <dmsmith555 at yahoo.com>:
>> I think that this may expose a bigger problem. I don't think the
>> is backward compatible. That is, if the files are not sequenced as
>> expected, then the content of the personal commentary might not be
>> readable by the newer code. BibleTime (and perhaps Xiphos) might
>> need a
>> way to identify that there is a problem migrate from the old format
>> the new.
> Does this mean that if someone has written a personal commentary with
> his 32-bit machine he can't read or use it in his new 64-bit machine?
If the personal commentary is created with the new code, it will be
If it was created before, it is still not portable.
> Or even that his commentary is useless after upgrading the software to
> a newer version?
I hope I am wrong, but that is my understanding: The commentary is
useless after that point.
> If problem is in file names, could someone at least write a conversion
> script or a compilable cross-platform program which does the
The problem is several fold. (I hope I am wrong on all accounts, but
this is my understanding.)
First, there is a file that holds the value used to construct the next
file name. That number is currently corrupt. Using that and
incrementing from there might work, but that is only if there are no
files having a name with a higher number. From what I observed, the
numbers are not sequential, so if that's the case, it is just luck.
The second problem is that there is an idx file that holds the binary
integer value for the file. This is read as a binary number, and
translated into a character representation and then the file name is
constructed from that string. The new code will interpret the binary
value differently. So it won't find the right entry.
The final problem is that once the module is created platform
dependent, it is not understandable on a different (endian or number
width) architecture at all. This is true with 1.5.11 and 1.5.12.
Again, I hope I am wrong.
If I am right, then I think a migratory path should and could be
provided for the module.
One way would be to create an new driver that does the right thing,
revert the current driver to the old behavior, create a new personal
commentary module that uses the new driver. With this, it would be an
easy thing to write a conversion routine that reads the raw entries in
the old module, one at a time, and writes them to the new module.
There could also be code that would see that there is an old style
personal commentary and do the update on behalf of the user.
While I can code in C++, I am not the right person for the job. It has
been too long since I have done that kind of coding. Now if it were
Java, that would be a different story.
There is another issue with 1.5.12 that needs to be tackled and that
is of a v11n personal commentary. I.e. that is to include the
apocrypha. I think that Xiphos is on the right track when it allows
many different personal commentaries. I think it will be important for
the front-end to create a personal commentary according to the v11n
wishes of the user.
This discussion really belongs on sword-devel. Not here. Other than to
urge that 1.5.11 SWORD is released and corresponding BibleTime and
More information about the Pkg-crosswire-devel