[sword-devel] load v11n from file

[Troy A. Griffitts]

Konstantin,

You make a great and convincing case for proceeding down path #2.
>     2. each module may have its own v11n, no dynamic shared v11ns


Path #2, though, disregards our objective to ultimately provide a way to
position Bibles of differing v11ns to the same content.


I would love to forget about trying to enumerate and define
versification systems (I'm sure Chris would as well), and to stop asking
each Bible module maker to pick which system best represents their data.

We currently have 13 systems in our engine.  Eventually we need to
extend VerseMgr with a facility to map these between one another
(possibly your implementation).

You have stated that you have tried with your code

> KJV(A) <-> Synodal <-> Vulg <-> NRSV v11ns

This implies there exists such a thing as a named list of versification
system in our engine (i.e., NOT path #2).

If you allow a module developer to bypass naming which versification
system their module uses, you would still somehow like them to define
how it maps to other Bibles.  I don't see how this is practical without
a named set of known v11n system in the engine.

I cannot imagine a module developer ALWAYS defining how their module
maps to every other system.

I can imagine a module maker saying, "I am basically "Synodal", but have
these 5 exceptions, and here is how these 5 exceptions should be handled
in relation to "Synodal."

And then our future mapping system can do it's best with this information.

But I believe we still need to enumerate a list of officially supported
v11n systems and have module developers choose which one to use.



I'm not happy about the extra work, but do you agree it is necessary?

Troy





On 14/07/11 19:39, Konstantin Maslyuk wrote:
>> 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
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page