[jsword-devel] Key issues

DM Smith dmsmith555 at yahoo.com
Mon May 12 17:30:55 MST 2008


On May 12, 2008, at 5:36 PM, Brian Fernandes wrote:

> I'm upgrading FireBible to handle Genbooks, Dictionaries, Glossaries  
> and
> probably Daily Devotionals too, but I'm running into a few issues  
> with keys.
>
> First, a little background on how FB works:
> When you select a Bible, Book and Chapter in the FB interface, that
> selection is converted into a URL (e.g. bible://gen.1). The URL is  
> then
> "loaded", as if you had typed it into the address bar yourself and
> pressed enter. Firefox then passes that URL onto FB's "bible" protocol
> handler. The protocol handler picks up the active
> Bible(org.cw.js.book.Book) from the combo box in the UI and then calls
> book.getKey("gen.1") to get a key. This key is then used to retrieve  
> the
> data to be displayed.
>
> Problem 1:
> The problem with this approach, is the fact that the URL does not
> contain the bible(book) name/Id. For example, if you bookmark the link
> bible://gen.1 when viewing the ESV bible, the next time you open the
> bookmark, if you have the ACV bible selected in the combo you will see
> ACV text instead of ESV.
>
> This also causes an issue with the history. For example, if you open
> Gen.1 in ESV, then select ACV and go to Exo.5 and click back, you will
> see Gen.1 in ACV, not in ESV.
>
> In custom software I could keep track of the bibles myself and set the
> bible accordingly on back / forward, but here I'm trying let Firefox
> take care of all the heavy lifting. By using the URL approach outlined
> above, I have free History support (except for this problem) from
> Firefox to the same extent as regular HTTP URLs in different tabs and
> windows. It is still possible for me to override back / forward  
> behavior
> but it is non trivial and could be avoided if I could include the book
> Id in the URL instead. My protocol would then retrieve the book from  
> the
> URL instead of the UI.
>
> I can do something custom here but wanted to know if there have  
> already
> been any discussions on this subject and if there already is a format
> for including the book Id in bible URLs.

We've discussed this on sword-devel and agreed on a spec for it:
sword://KJV:Gen.1.1


This is an OSIS id with a workID of KJV.

If it is helpful, the workID can be further specified with a type:
e.g. Bible.KJV, Dictionary.StrongsHebrew



>
>
> Problem 2:
> I'm trying to use the same URL approach with Gen books. When the user
> selects a particular node in the Gen book tree, I convert that key  
> into
> a URL and attempt to load that. Besides running into Problem 1 again
> (since the book Id is not part of the URL), I have an additional
> "textual uniqueness" problem. If you look at "Sermons on Gospel Themes
> by Charles G. Finney" you will notice that there are several "pages"
> titled "REMARKS", consequently, "REMARKS" is also the Key name for all
> these pages.

Again, prefixing the with the work to start.

GenBook's index is a tree with all the inherent requirements and  
problems of a tree. Specifically, siblings have a uniqueness  
requirement, but non-siblings do not.

As you can guess, the key to a GenBook entry is the entire path from  
the root. Sword reserves '/' as a path separator.

I don't know that JSword supports lookup by path yet. But that's what  
we are working for. Internally, JSword builds the tree by getting the  
children of a node along with it's index info (offset and length) into  
the data file. So in BD when one clicks on a node in the tree, that  
node knows where the data is in the module.


>
>
> Given a Gen book and a URL like "bible://REMARKS/" the first page  
> tiled
> REMARKS is retrieved, not necessarily the REMARKS page you selected.
> This is easy to fix if I use the original Key object that was  
> selected,
> but with my URL approach, passing an object along is out of the  
> question
> (note that these URLs should ideally be usable across Firefox  
> sessions,
> if you restart the browser, it should still bring up the same content;
> so having the protocol handler look up some info external to the URL
> will only work for a given session).
>
> My solution here was to create a custom URL which could contain the  
> key
> names for all the ancestors of the desired key, delimited by an
> acceptable character (may be difficult to find one). The protocol
> handler would then break up the URL and regenerate the desired Key.
>
> Again, has any work been done in this area or does JSword have the
> ability to generate a textually unique key (something that would  
> include
> the ancestral path?).
>
> Any suggestions on how to deal with these issues in a standards
> compliant way are welcome (or perhaps we need to extend the existing
> standard :)),
> Brian.
>
> P.S. I just found a bug in BD 1.0.7 where Gen books pages have the  
> same
> names.
>
> 1) Select the any "REMARKS" page (A). Observe text.
> 2) Select another "REMARKS" page (B) without selecting anything else  
> in
> between. Observe that text is not updated as expected.
> 3) Select any other page with a different name and then select B  
> again.
> Observe that text has now been updated (this should have happened at
> step 2).

When Jira is fixed, I'll log this. Remind me if I don't remember.


In Him,
	DM






More information about the jsword-devel mailing list