<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>My very late reply to this whole discussion:</div><div><br></div><div>I love the idea of a scope. As Ben points out, a user would be able to tell before they install a module that a commentary is only for specific books of the Bible or a Bible module is NT or OT only. After that, we would easily be able to determine which books to display for navigation purposes. If there was a method in the engine, Troy points out that it can be very optimised, which would be good for post-installation, but how optimised will it be for running on handheld devices (which I guess is the main scenario I am interested in!)?</div><div><br></div><div>I think I would rather that the scope was set manually in each conf and wasn't something that maintainers had to run on their repositories or anything like that. For a majority of modules out there, an empty scope would be sufficient, as long as we defined an empty or non-existant scope reverted to ALL (based on the v11n) or something like that. :)</div><div><br></div><div><br></div><div>Thanks, ybic</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>nic... :)</div><br>
<br><div><div>On 13/02/2012, at 7:47 AM, Ben Morgan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">By having things in the .conf file, frontends can potentially show those details in install manager. That's about the only advantage I can see in having it in the .conf file (excluding any speed issues, which you say are negligible).<br>
<br>I'd say that any precomputed module scope would have to be to chapter granularity at its finest, and possibly only book granularity.<br><br clear="all">God Bless,<br>Ben<br>-------------------------------------------------------------<br>
<div>
<div>For I have no pleasure in the death of anyone, <br>declares the Lord <span style="font-variant:small-caps">God</span>; so turn, and live.”<br>Ezekiel 18:32 (ESV)</div>
</div>
<br><br>
<br><br><div class="gmail_quote">On Mon, Feb 13, 2012 at 3:07 AM, <a href="mailto:scribe777@gmail.com">scribe777@gmail.com</a> <span dir="ltr"><<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right, this opens up all kinds of discussion, as you point out.<br>
<br>
* if we have scope= in the .conf, what does this mean?<br>
Author intent?<br>
What does that mean?<br>
A checksum for their actual content (I don't like this)<br>
An entire sub- v11n definition (I don't like this)<br>
Simply a cache of the derived actual module content (I don't like this)<br>
<br>
So, I think it's safe to say that I don't like anything about having it in the .conf<br>
<br>
* if we provide a method in the engine to get the actual scope, what does this mean?<br>
<br>
Frontend are strongly advised to only display navigation for actual content?<br>
As Jonathan pointed out, if the ESV doesn't include 1 verse which is in the KJV v11n scheme, do we really want to limit the user from selecting this verse?<br>
<br>
Maybe only suggest using for book display?<br>
... only for book and chapter display?<br>
<br>
Dunno. I can whip up a very optimized method to return the actual module scope, so I'd rather not simply cache it in the .conf file with scripts which are yet another requirement for repository maintainers to run.<br>
<br>
Troy<br>
<div class="im"><br>
Jonathan Morgan <<a href="mailto:jonmmorgan@gmail.com">jonmmorgan@gmail.com</a>> wrote:<br>
<br>
>Hi Troy,<br>
><br>
>On Sat, Feb 11, 2012 at 7:39 AM, Troy A. Griffitts<br>
><<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>>wrote:<br>
><br>
>> Hey guys. I'm remember this thread from a while back am to lazy to<br>
>go<br>
>> back and look.<br>
>><br>
>> Please remind me why we want a .conf entry and not a call like:<br>
>><br>
>> SWMgr library;<br>
>> SWModule *kjv = kjv = library.getModule("KJV");<br>
>> VerseKey testKey = "jn.3.16";<br>
>><br>
</div>>> // ------------------------------**--<br>
>> ListKey range = kjv.getModuleScope();<br>
>> // ------------------------------**--<br>
<div><div class="h5">>><br>
>> range = testKey;<br>
>><br>
>> if (range.Error()) cerr << testKey << " is not within the range: " <<<br>
>> range.getRangeText() << endl;<br>
>><br>
>><br>
>> The only thing missing is the SWModule::getModuleScope() method which<br>
>> could easily be written to scan the module and produce an appropriate<br>
>> ListKey.<br>
>><br>
>><br>
>> The .conf file is an opportunity for inconsistency. It can be a<br>
>useful<br>
>> checksum or a pain in the butt maintenance nightmare and I'm thinking<br>
>the<br>
>> latter.<br>
><br>
><br>
>As I would see it, a principle difference would be author intention.<br>
>If we<br>
>have a conf file, then we know that (at some point) the author intended<br>
>to<br>
>limit the range in this way. However, if we have a module we do not<br>
>know<br>
>that the author deliberately intended particular parts to be excluded,<br>
>or<br>
>whether they left them out by accident. This is particularly<br>
>problematic<br>
>if it is just individual verses left out. Does that mean in any<br>
>navigation<br>
>we have we should explicitly not display those verses? For example,<br>
>consider Mark 9:46 in the ESV. It is not present in the text (though<br>
>the<br>
>gap is there because it was present in the KJV, and the same<br>
>versification<br>
>is being used), but arguably you don't want the application to tell you<br>
>"this verse isn't present in the ESV" or to not allow you to select<br>
>Mark<br>
>9:46 or link to it or anything like that.<br>
><br>
>Thoughts?<br>
><br>
>Jon<br>
><br>
><br>
>> On 02/10/2012 04:35 PM, David Haslam wrote:<br>
>><br>
>>> Let's not forget that some modules are for a work in progress by the<br>
>>> translators.<br>
>>><br>
>>> e.g. A New Testament only module may have plenty of cross-references<br>
>to OT<br>
>>> passages, in anticipation that the translation would one day<br>
>eventually be<br>
>>> completed.<br>
>>><br>
>>> And - yes - as DM noted, xrefs for modules that are scope-restricted<br>
>>> should<br>
>>> be linkable for parallel modules that contain the missing books,<br>
>etc.<br>
>>><br>
>>> David<br>
>>><br>
>>> --<br>
</div></div>>>> View this message in context: <a href="http://sword-dev.350566.n4./" target="_blank">http://sword-dev.350566.n4.</a>**<br>
>>><br>
><a href="http://nabble.com/Av11n-and-coverage-**tp4265350p4376618.html" target="_blank">nabble.com/Av11n-and-coverage-**tp4265350p4376618.html</a><<a href="http://sword-dev.350566.n4.nabble.com/Av11n-and-coverage-tp4265350p4376618.html" target="_blank">http://sword-dev.350566.n4.nabble.com/Av11n-and-coverage-tp4265350p4376618.html</a>><br>
<div class="im">>>> Sent from the SWORD Dev mailing list archive at <a href="http://Nabble.com">Nabble.com</a>.<br>
>>><br>
</div>>>> ______________________________**_________________<br>
>>> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
>>><br>
><a href="http://www.crosswire.org/**mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/**mailman/listinfo/sword-devel</a><<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a>><br>
<div class="im">>>> Instructions to unsubscribe/change your settings at above page<br>
>>><br>
>><br>
>><br>
</div>>> ______________________________**_________________<br>
>> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
>><br>
><a href="http://www.crosswire.org/**mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/**mailman/listinfo/sword-devel</a><<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a>><br>
<div class="im HOEnZb">>> Instructions to unsubscribe/change your settings at above page<br>
>><br>
>_______________________________________________<br>
>sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
>Instructions to unsubscribe/change your settings at above page<br>
<br>
</div><span class="HOEnZb"><font color="#888888">--<br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</div></div></blockquote></div><br>
_______________________________________________<br>sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br><a href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>Instructions to unsubscribe/change your settings at above page</blockquote></div><br></body></html>