My very late reply to this whole discussion:
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!)?
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. :)
Thanks, ybic
nic... :)
On 13/02/2012, at 7:47 AM, Ben Morgan wrote:
> 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).
>
> I'd say that any precomputed module scope would have to be to chapter
> granularity at its finest, and possibly only book granularity.
>
> God Bless,
> Ben
> -------------------------------------------------------------
> For I have no pleasure in the death of anyone,
> declares the Lord God; so turn, and live.”
> Ezekiel 18:32 (ESV)
>
>
>
>
> On Mon, Feb 13, 2012 at 3:07 AM, scribe...@gmail.com <scr...@crosswire.org>
> wrote:
> Right, this opens up all kinds of discussion, as you point out.
>
> * if we have scope= in the .conf, what does this mean?
> Author intent?
> What does that mean?
> A checksum for their actual content (I don't like this)
> An entire sub- v11n definition (I don't like this)
> Simply a cache of the derived actual module content (I don't like this)
>
> So, I think it's safe to say that I don't like anything about having it in
> the .conf
>
> * if we provide a method in the engine to get the actual scope, what does
> this mean?
>
> Frontend are strongly advised to only display navigation for actual content?
> 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?
>
> Maybe only suggest using for book display?
> ... only for book and chapter display?
>
> 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.
>
> Troy
>
> Jonathan Morgan <jonmmor...@gmail.com> wrote:
>
> >Hi Troy,
> >
> >On Sat, Feb 11, 2012 at 7:39 AM, Troy A. Griffitts
> ><scr...@crosswire.org>wrote:
> >
> >> Hey guys. I'm remember this thread from a while back am to lazy to
> >go
> >> back and look.
> >>
> >> Please remind me why we want a .conf entry and not a call like:
> >>
> >> SWMgr library;
> >> SWModule *kjv = kjv = library.getModule("KJV");
> >> VerseKey testKey = "jn.3.16";
> >>
> >> // ------------------------------**--
> >> ListKey range = kjv.getModuleScope();
> >> // ------------------------------**--
> >>
> >> range = testKey;
> >>
> >> if (range.Error()) cerr << testKey << " is not within the range: " <<
> >> range.getRangeText() << endl;
> >>
> >>
> >> The only thing missing is the SWModule::getModuleScope() method which
> >> could easily be written to scan the module and produce an appropriate
> >> ListKey.
> >>
> >>
> >> The .conf file is an opportunity for inconsistency. It can be a
> >useful
> >> checksum or a pain in the butt maintenance nightmare and I'm thinking
> >the
> >> latter.
> >
> >
> >As I would see it, a principle difference would be author intention.
> >If we
> >have a conf file, then we know that (at some point) the author intended
> >to
> >limit the range in this way. However, if we have a module we do not
> >know
> >that the author deliberately intended particular parts to be excluded,
> >or
> >whether they left them out by accident. This is particularly
> >problematic
> >if it is just individual verses left out. Does that mean in any
> >navigation
> >we have we should explicitly not display those verses? For example,
> >consider Mark 9:46 in the ESV. It is not present in the text (though
> >the
> >gap is there because it was present in the KJV, and the same
> >versification
> >is being used), but arguably you don't want the application to tell you
> >"this verse isn't present in the ESV" or to not allow you to select
> >Mark
> >9:46 or link to it or anything like that.
> >
> >Thoughts?
> >
> >Jon
> >
> >
> >> On 02/10/2012 04:35 PM, David Haslam wrote:
> >>
> >>> Let's not forget that some modules are for a work in progress by the
> >>> translators.
> >>>
> >>> e.g. A New Testament only module may have plenty of cross-references
> >to OT
> >>> passages, in anticipation that the translation would one day
> >eventually be
> >>> completed.
> >>>
> >>> And - yes - as DM noted, xrefs for modules that are scope-restricted
> >>> should
> >>> be linkable for parallel modules that contain the missing books,
> >etc.
> >>>
> >>> David
> >>>
> >>> --
> >>> View this message in context: http://sword-dev.350566.n4.**
> >>>
> >nabble.com/Av11n-and-coverage-**tp4265350p4376618.html<http://sword-dev.350566.n4.nabble.com/Av11n-and-coverage-tp4265350p4376618.html>
> >>> Sent from the SWORD Dev mailing list archive at Nabble.com.
> >>>
> >>> ______________________________**_________________
> >>> sword-devel mailing list: sword-devel@crosswire.org
> >>>
> >http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.crosswire.org/mailman/listinfo/sword-devel>
> >>> Instructions to unsubscribe/change your settings at above page
> >>>
> >>
> >>
> >> ______________________________**_________________
> >> sword-devel mailing list: sword-devel@crosswire.org
> >>
> >http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.crosswire.org/mailman/listinfo/sword-devel>
> >> Instructions to unsubscribe/change your settings at above page
> >>
> >_______________________________________________
> >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
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
_______________________________________________
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
