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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
