[sword-devel] Parallel display of modules with varying v11ns
kostyamaslyuk at gmail.com
Wed Feb 26 13:45:06 MST 2014
Sorry for previous attempt.
2014-02-26 23:00 GMT+04:00 Troy A. Griffitts <scribe �� crosswire.org>:
> One positive thing from the previous thread is the reminder of Kosta's
> proposed implementation for translation between modules of varying v11n.
> The accusation of irresponsibility is warranted, not for delaying the patch
> submission, but for delaying the discussion toward a resolution and buyin by
> a consensus of frontends.
Please do not feel accused. I only would like to return to the course
of constructive dialogue.
> To sum up:
> We have refactored and isolated translation to a single point within the
> engine. Basically, when you set the value of one VerseKey from a VerseKey
> with differing v11n, translation will happen. This propogates naturally to
> many places in the engine. For example it will allow one to set the LXX
> module from a key obtained from the KJV module:
> The question still on the table is: how useful is this for the primary use
> case of displaying in parallel modules with varying v11ns?
I do not see another way but to leave it as is, and remake it after we
got any feedback. Few things changed in frontends since your first
attempt and i doubt anyone thought about it seriously.
> A secondary question is how can we optimize, in both speed and size, the
> translation. The JSword team is beginning to implement their own mechanism
> and I would like to hear about their experience.
It is not clear to me, what is speed and size of translation (i just
ask to be crystal clear, because beyond some point i can not
understand sense of sentence).
As Chris mentioned performance issues, i would like to remind that i
have suggested following pipeline (that is implemented yet):
1. Create table of mapped verses, at moment there are xml's with
something like ccel.org use
I would suggest to move to anything like OSIS if possible, so someone
can export mapping data from OSIS xml with original text. In other
words if we could add to osis xml-s with Biblical text some data that
would tell how particular verse maps to KJV, we will be able to export
everything from that xml: text, mapping data, canon. At moment there
is need to make additional file that have canon definition and mapping
2. run python script that convert that xml to c++ compliant data that
would be inserted to corresponding canon.h file and compile library
with that data.
Data that is exposed to engine is optimized and whole system works fast.
I would like to have common mapping data among both Sword and JSword.
> There are open threads on this with many of my, and others, thoughts and
> concerns. I would appreciate it if commenters might consider searching the
> list history before commenting.
> My theoretical question is, what logic do we want to use to create a
> parallel display? There are many hard cases we haven't resolved, even if the
> resolution is "we simply don't handle that, and what you'll see is X."
Again, few people thought about convenience of implementing parallel
display in own frontend. No one post own ideas on this list about it.
So i think we are not ready to discuss it at moment.
My patch only introduce way to find corresponding content among
If some one feels strong enough to implement parallel display let him
have a try and wait his suggestions.
Second one, parallel display facilities you would like to implement in
Sword, before my work would be included, will take another long time,
possibly longer then if we include my work first.
Release smaller, release often.
P.S. i agree with general spirit flying on this list, we want changes
and some movement.
> I know the STEP tools have a parallel display implementation. I have no idea
> if its behavior in corner cases is acceptable to most.
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> sword-devel mailing list: sword-devel �� crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel