[sword-devel] load v11n from file

[Konstantin Maslyuk]

> Practically, this is easy to implement.  The entire concept of managing
> versification systems is contained in this file:

I know, i saw that there is no real need to store v11n description
statically.

> This IMPLEMENTATION isn't where the work lies.  Externalizing v11n
> systems has always been a longterm goal.

There are two real ways:
	1. module installation may also install v11n to common folder
	2. each module may have its own v11n, no dynamic shared v11ns

First way really brings up too many questions. Second is little more  
simple but
would result in performance overhead (in memory, because we can not use  
NT/OT parts
separeted and in speed when map verse between v11ns).

> The complexities lie in detailing policies.  How do these get installed?
1: on module installation module manager should copy file of v11n into  
v11n.d folder
2: v11n file is a part of module and is located in same folder as module

>  Are they versioned?
1: yes, files of v11n should have different local name, maybe using suffix
2: versioned just as a module

> Are they named?
1: we should trace name collisions in crosswire and third party modules
2: own v11n have same name of a module, even if there are duplicate  
modules, with maybe
different versions, on module initialization module will be renamed and  
have unique name.
But we also need to rename module if module name coincide with any  
registred(builtin/static)
v11n name.+

> Does every module supply its own v11n or does it name the versification  
> it uses and
> the engine looks it up in a central repository?
> If a module supplies its own system and
> names it KJVA, is that system installed to a central location available
> for other modules to use?  What if another system also supplies a KJVA
> but it is different?
1: this way makes such confusions, yes we can use and update external v11n  
and have
its benefits, but this is a step into obscurity. We need to make new  
update system for
v11ns.
2: every thing is ok. we need to update each module manually if was  
investigated that v11n
need to be changed but module will always works just as it was tested last  
time. Besides
we have good module update system.

> Mappings between...
1, 2: now mappings made statically, no reason why it shouldn't be in file  
too. It is
just a data table of rules.

> VerseKeys currently know which
> versification system they are using (by NAME; you can ask
> VerseKey::getVersificationSystem())-- and there is a mechanism in the
> framework which lets VerseKeys reposition themselves to the
> corresponding location from another system-- though as you know, no
> implementation for this translation is yet in place.
1,2: there will no difference for VerseKey from where was loaded v11n:  
static memory
or file
Yes work over v11n mappings was stopped, i don't know why. I have tested  
all cases
for KJV(A) <-> Synodal <-> Vulg <-> NRSV v11ns.

> If modules supply
> their own named v11n systems, how will this affect this concept?  Will
> VerseKeys live any longer outside the concept of a module if they need a
> module-supplied versification?  Again, what if VerseKeys have the same
> name supplied with their module v11n but differ slightly, how will this
> affect the mapping system?
1,2: again, for VerseKey there is no difference

> We could move forward slowly down the path by:
>
> 1) reading privately named v11n systems from
>
> <module_library_root>/v11ns.d/ (same as we read locales.d/)
>
>
> 2) delivering our offical v11ns other than KJV under v11ns.d/ along with
> the same delivery of locales.d/ (at library install time). This has the
> effect that just as unofficial locales can current be supplied,
> unofficial v11ns could also be supplied.

1: With concept of different local paths of modules storage (work dir, app  
data,
users home), there may be that v11n for module can be not found.

> 3) update InstallMgr to deliver locales.d/ and v11ns.d/
> This has always been planned for locales.d/, but locales.d is a much
> easier situation; nothing /should/ ever break if we supply an updated
> locale on top of an old one.
>
> (1) will give you the ability to create modules and test them with your
> own v11n system, but will not yet give you the ability to deliver your
> module easily with existing apps.
v11n would also be exported from source file

> (2) and (3) are necessary for our long term delivery of official v11n
> systems.
>
> Beyond this we need to discuss how to let module developers supply their
> own system without sabotaging other modules' systems, use a v11n if it
> is already installed, share their system and mappings for other modules
> to use until it is supplied in the official repository, only pull from
> the official repository v11ns for modules installed, etc...
1: there is need of a lot attention from crosswire developers, to get this
way work proper without collisions and non-coordination
2: create, test, deliver is simple. just tell in *.conf file to load
v11n from module