<html><head><meta http-equiv="Content-Type" content="text/html charset=koi8-r"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 5, 2013, at 5:43 AM, Костя Маслюк &lt;<a href="mailto:kostyamaslyuk@gmail.com">kostyamaslyuk@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><p dir="ltr">
05.06.2013 5:32 пользователь "Nic Carter" &lt;<a href="mailto:niccarter@mac.com" target="_blank">niccarter@mac.com</a>&gt; написал:<br>
&gt; I guess we need to have some sort of implementation with which to try this out with. I remember that trying to create a cLucene search index on my old iPhone 3G was sufficiently silly that I removed that functionality in PS. But I needed to test it to confirm that it was a stupid idea to allow users to attempt it. (I would say the same for BibleTime mini &amp; say that 2.5hrs is way too long to even suggest a user plug in their phone and run it overnight! But that's just my sanity shining through, and I'll resume my insanity in a moment)...<br>


&gt;</p><p dir="ltr">This statement forced me to check: with BtMini i got nine minutes to create clucene search index for KJV (iphone 3gs 6.1 firmware). Can't believe that 3g to 3gs performance difference can be up to 16 times.</p><p dir="ltr"><br></p><p dir="ltr">Coming back to conversation subject, there can be i didn't noticed too, whether idea with module-supplied-v11n was rejected? Compared to Scope feature it is more powerful flexible, do not increase load on frontend, and finally simple to realize. I even consider ability to provide several v11n schemes for one module, whether it is necessary for user to turn off deuterocanonical content.</p></div></blockquote></div><div>The intention of Scope was to declare what was actually in the module. It was not meant to hide module content.</div><div><br></div><div>I don't know what thread it was. But my understanding is that every time this is brought up the answer is we aren't going to do that using the current module format but rather using a gen book format (and VerseTreeKey?).</div><div><br></div><div>I think that part of it may be the desire to have mappings from one v11n to another. Having "arbitrary" per module v11n make the task hard.</div><div><br></div><div>The problem of having multiple v11n per module is that is not how a v11n works. In the non-compressed module, there are two parts per testament: an index and a dat file. The v11n is used to convert a Bible reference into an index into the dat file. Basically, the structure of the v11n is given as counts of verses by chapters. If one v11n is missing content of the other, its index for every verse following will differ.</div><div><br></div><div>There are two basic solutions:</div><div>a) Build the module twice, such as is done with the KJV.</div><div>b) Change the frontends to turn off/on non-canonical material. This requires distinct knowledge of the v11n to get it right.</div><div><br></div><div>a) is a lot easier to do.</div><div><br></div><div>If the frontends will only display books, chapters and verses that are actually in a module (e.g. in a verse picker) then we may not need both KJV and KJVA, NRSV and NRSVA, ..., but only the one that contains the apocrypha. In fact we probably can use the NRSV(A) for the KJV and get rid of the KJV v11n. But that day is a long way off.</div><div><br></div><div>Hope this helps.</div><div><br></div><div>In Him,</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>DM Smith</div></body></html>