[sword-devel] Important questions

Troy A. Griffitts sword-devel@crosswire.org
Fri, 16 Mar 2001 18:50:41 -0700


Joachim,
	Had to backout one of the typename changes that you made for Borland
C++Builder to like it.  Please let me know if you needed them both. 
I've commited what works for me.

>   -Most of the Sword frontends deal with bookmarks. We want this to be
> frontend- and OS independent, so that the users can easily share and exchange
> their bookmark files. There may be 2 ways to achieve this: a) work out a
> standard for bookmark files and b) implement bookmark management in sword. It
> should support different locales and be module independent.

Yes.  I agree.  Let's let's make a bookmark class.


>  -We _need_ some way to determine which books, chapters and verses of a
> commentary (and bible) are available.

We actually don't have that information readily available.  The 0 length
entried in the index are the entries that are not available, so we could
scan the module once and save this information.  If we go to a dynamic
canon config for other verse numberings, then each module should
populate the VerseKey::books structure themselves, and you can just scan
this to get the available entries.

There are so many uncertain things about this approach though, which is
why it has been put off for so long.

	o  You will no longer be able to share keys between modules.
	o  We will need some kind of dynamic mapping mechanism, because now,
the common mapping is done at module creation time by mapping all verses
to KJV numbering.  Without this, we will still need a way to link
between variant numberings
	o  Numberings will not have the same index values, so when setting a
key, a literal parse from one module's VerseKey to another will be
necessary, making it slower.

Anyway, all this to say.... It's not easy, or readily available, or I
would do it for you right now.

Is there a way around it?  Why do you need this information?  I think
you know you can get KJV numberings from the VerseKey::books structure,
right?


>  -We expect a copy constructor in swmodule to be the easiest way of
> implementing thread safe searching in bibletime. But maybe there are better
> solutions? BibleCS also crashes when browsing a module while it is being
> searched.

Planned.  Actually, I was also trying to figure out a way to make
Searching thread-safe without copying the module.


>  -The search progress implementation does not work well with user defined
> scopes.

Progress for non-accelerated searches is determined by module position. 
This is why it looks silly if you're searching, say, NT, you'll start at
about 70%.  Not good.  Any takers to do the math?  Actually,
VerseKey::Index() should not be used for progress, instead, since SWKey
defines the range, SWKey::getProgress() or something should be written. 
This will let ListKey compute one way, and VerseKey with mins and maxs
compute another way.  Actually, ListKey will still be hard because keys
can be nested x levels.  Maybe a SWKey::entryCount() AND
SWKey::getEntryOffset().  These will only be useful on Traversable()
SWKey's, though, not lexicons, etc.  hmmmm...  Seems like we need a
little more thought for this one...


>  -We would like the current status of the new search engine implementation.

Not sure.  Barry Drake just volunteered to do an implementation.  :) 
(just kidding, Barry)


> We'd be grateful for comments + help with these issues because they are
> important for the future development of BibleTime, and especially the 1.0
> release.
> We also wish to thank all those who have been contributing to the sword
> project and making the development of bible study programs possible. Thank
> you for all the time and love you have been investing to serve others.
> May God bless you!
> 
> Joachim + Martin
> 
> P.S. Troy thank you for the cool config interface. Thanks for all your help.

No problem.  Like I said, hope it compiles for you now.  If not we'll
have to do some #ifdef's