[jsword-devel] Key issues

Brian Fernandes infernalproteus at gmail.com
Mon May 12 14:36:24 MST 2008


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.

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.

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).



More information about the jsword-devel mailing list