[sword-devel] Why I think there should be a Sword 1.5.4

[Chris Little]

I believe there are a lot of important things missing from Sword that
should be addressed before we move to 1.6.0.  I feel they are
sufficiently important that we should address them immediately rather
than waiting some number of years until we start working on 1.7.  And
they will require significant changes to the API, so they should not be
done during 1.6.

I get the impression that our users and front end authors would
appreciate a 1.5.3 release to be sooner rather than later, in which case
I think we ought to plan on a 1.5.4 release.  The alternative (in my
opinion) would be to postpone the 1.5.3 release for a few months or
however long it takes to complete the tasks I will list as important (in
my opinion) to 1.6+.

Troy had said he planned to begin 1.6 immediately after 1.5.3.  And that
seemed like a good idea to me, so I passed that information on to
others.  Now I think that's not a good idea, having thought about 1.5.3
does not currently have that I would really like to have before we hit
1.6. :)

Anyone who is interested in working on one/some of these tasks, please
chime in. :)


Tasks I think are important for 1.5.3:

1) i18n

We need to internationalize the whole Sword API.  We i18n support for
the books, but need the rest of the messages to be separated into
resource files.  My opinion is that we should implement our own i18n
system similar to the current system for book names.  We could use ICU,
but I think that would be overkill for our needs, and adds unnecessary
complexity & dependency on ICU.

I18n includes not only translated messages but also formats, such as
using commas instead of colons as chapter/verse separators.

2) general book support

I think this is relatively important.  It is the single most noticeable
feature that is missing from Sword but present in almost every other
Bible software package (OLB, Logos, e-Sword, ...).  Until we have this,
we're no better than BibleWorks.  Okay, bad example. :)

Troy & I (mostly Troy) worked on a scheme for storing & indexing general
books that should work very well.  It's based on a single hierarchy and
uses "TreeKeys" similar to the way a filesystem directory structure
works.  It will work very well for XML structured books (e.g. OSIS &
ThML texts).  I believe it is very important to also make a utility to
index ThML documents such that they can be easily used in Sword, without
modifying the document at all.  Compression should be handled also, but
should be a relatively straightforward port of VerseKey based
compression to TreeKey based compression.

3) expanded ciphering support

Ciphering support works on uncompressed Bibles & commentaries.  We need
to expand cipher support to work with compressed Bibles/commenatries, LD
modules, compressed LD modules, general book modules, and compressed
general book modules.

If some of these already work, we still need conversion utilities, such
as RawLD->ciphered RawLD (or ciphered zLD).

4) apocrypha support

We just plain need it.  I'm not advocating that we handle multiple
versifications yet.  (If Troy wants to advocate that, I'll happily go
along with it, but I suspect he'll prefer to postpone that until 1.7.)

This is a pretty simple task, simply requiring additions to canon.h &
VerseKey, I believe.  The only real decisions are which versification to
choose (KJV? NRSV? XYZ?) and how to handle verses in the additions to
Daniel & Esther that have two names (one in the apocryphal additions,
one in the Greek canonical book).

5) UTF-8 regex support

We can probably use Perl's regex code in place of the GNU regex stuff we
currently have.  This would also release us completely from needing to
follow GPL; all other borrowed code is BSD or similar licensed.  So we
can pretty much license Sword as we please (and create binary-only
releases if necessary).

6) bookmark interface

There was a bit of talk about this a while back but I think it's been
somewhat forgotten.  A common bookmark format for all the front ends,
accessible through the Sword API, should be decided upon.  I don't know
much about this, but I understand BibleCS already has a bookmark format
that uses the SWConfig classes, so we could simply work on pushing any
generalizable bookmark stuff in BibleCS back into the libarary.

7) swtext++

Bible modules should advance to the next unique verse when they are
++'d, like commentaries do, incases of linked verses. If the next verse
is blank, it should advance to that verse to address issues of omitted
verses. All blank verses should be considered unique so that two
consecutive blank verses will both be iterated over.

This lets us add Bibles that have single text units that span verses
(e.g. where "Mt 1:1-5" is a single unit or where verses are not
identified, only chapters).  This is a pretty simple problem and can
probably be handled by 1.5.3.

8) search on (currently) stripped items

Currently, Strong's numbers, morph tags, etc. are stripped out for
searches.  There are of course circumstances where a person would
explicitly want to search for a given morph tag or Strong's number, so
we should make sure a facility for this exists.





Add to the list if you think there are any other items that are
important to have in Sword BEFORE 1.6.


--Chris