[sword-devel] Alternate Versification

[Greg Hellings]

DM,

On Mon, Mar 16, 2009 at 12:03 PM, DM Smith <dmsmith at crosswire.org> wrote:
> I've been looking at the code regarding Alternate Versification (aka av11n
> and v11n; I've seen these abbreviations by Troy, Chris and others).
>
> It looks solid. The purpose of this note is to give it a big thumbs up.
>
> Basically here is what I see: (Chris, Troy, correct me where I am off base!
> Please!)
> Today (1.5.11 and earlier) speed is a major consideration and canon.h
> provides for that. The core functionality of looking up a verse or intro is
> to convert a verse key into an offset in the module's index. Without going
> into it in great detail, the module, testament, book and chapter
> introductions are addressable in the index, as well as each verse.
>
> In 1.5.12, canon.h no longer includes a fast lookup for this. Instead it
> includes the KJV versification: books by name, number of chapters and number
> of verses per chapter. The new VerseMgr takes this and dynamically builds
> the old lookup table, hiding it behind it's API. The performance hit is
> taken once each time the program is run for each versification scheme that
> is requested.
>
> Chris has taken the CCEL versifications and wrote a perl program that uses
> them as input to generate the same structure for each versification.
>
> Currently, the VerseMgr does not know about the different V11Ns. It looks
> like that is all that is left for it.
>
> If I am understanding this correctly, this leads me to believe that GenBooks
> are not going to be used, but rather regular Bible modules. If this is true,
> it is a boon to commentaries as well, as commentaries are structured
> internally as Bibles. And it gives us compressed modules. And it gives us
> the speed of the Bible module (GenBook is very slow in comparison.)
>
> I had been concerned with GenBooks being used as osis2mod does
> transformations and the gen book importer did not.

Has there been any moves to reduce the amount of transformations
osis2mod performs, so that the stored format is even closer to the
import format (preferably lossless)?  What prevents all Bible modules
from being stored in an inherently OSIS format internally with the
indexes created by the engine simply leveraging certain points in an
OSIS file, rather than in a separate binary format?  It seems that
would be the most lossless format available, but I'm curious as to
what technical issues might prevent that from being the most desirable
method?

--Greg