[sword-devel] Why Sword?

[Chris Little]

In response to various open source Bible projects not using Sword as a
basis, I would like to post some propaganda on the website to encourage
people to use Sword rather than build their own solutions from scratch.
It's their right to do so, but I think they do so because of erroneous
or misguided conceptions that I would like to dispell.  Please read
through what I have written and contribute ideas and suggestions for
improvement.  I'm looking for comments on content, tone, gross
omissions, etc. especially from you folks who actually use Sword to
build software.

Thanks,
Chris

------------


Why Sword?

Over the last few months, I have noticed a number of new Bible programs
and projects crop up on the internet.  The question I always ask when I
see a new Bible software project start is why they aren't using the
Sword Project as an underlying API.  The only good reason I have yet
heard was from a project whose license was not compatible with the GNU
General Public License.  Aside from that, I can see no good reason.

If I may share a bit of personal history, I would like to explain how
and why it was that I came to work on the Sword Project.  Some three
years ago, I had an itch for better Bible software.  The free software I
was finding on the net was badly designed, clunky, and unextendable.
The software that was available for purchase was very expensive and even
less extendable.  I had begun to prototype a new MFC Bible reader, when
I was (thankfully) sidetracked.  The sidetrack was an urgent need to
build a Biblebot for an IRC channel.  I had located a Biblebot script
that used <a href="http://bible.theverge.com/brs.html">BRS</a>, but BRS
itself only came with the KJV.  After a bit of snooping through BRS, I
decided to look for alternative command-line driven Bible software on
Freshmeat.  I found none, but I did notice the Sword Project, which
touted itself as a Bible software API.  I figured this might be the
ticket because it would give me access to content creation tools, and I
figured it would be trivial to write a command-line driven tool if one
didn't exist.  The Sword Project wasn't in an especially pretty state at
the time.  The Windows front-end was still pretty immature, and this was
before BibleTime or GnomeSword had even started.  But the power of the
underlying library was enough to meet all my needs, and more, at the
time.

My needs at that time were relatively simple compared to what people now
expect full-featured Bible software to deliver, but the Sword Project
has matured greatly.  We have modeled its features on those of
successful commercial Bible software packages and on the suggestions of
pastors, scholars, missionaries, and laymen to meet their expectations.
We have worked to expand our library of texts and to implement more
multi-lingual capabilities in the engine.  In short, I would propose
that Sword's API provides the front-end author with the tools to meet or
exceed the capabilities and features of any piece of Bible software
currently available.

If I may, I would like to list some of the Sword Project's features and,
in the process, correct some misconceptions I have heard.

Sword is a cross-platform library.  Without a doubt, Sword runs on more
platforms that any other Bible program.  Linux (x86, PPC, ARM, SPARC,
and others), BSD, Solaris (x86 and SPARC), Win32, BeOS, and Mac OS X are
all supported platforms.  Since it is a non-graphical library, it is
graphics toolkit agnostic, but front-ends have been written for Windows,
GNOME, GTK, KDE, Qt/Embedded, X11, wxWindows, and ncurses.  Language
bindings exist for Perl, Python, and CLX.  And a sister project to port
Sword to Java is under way.  We also provide an ActiveX control and
interfaces for CGI and SOAP.

Sword provides a common, open module format with roughly 400 texts at
the time of writing.  The Sword Project already supports more texts than
any other free Bible software, and more Bibles than ANY other Bible
software.  But tools for creating new content are available with our
source distribution.  Sword uses a variety of different module formats
to meet the needs of our texts.  Older modules are in a raw format.
Newer texts are moving to compressed format.  Bibles/commentaries,
dictionaries, and general books each have their own formats.  And
copyrighted texts can be enciphered using the Sapphire II stream cipher,
which provides the protection of strong encryption along with the
simplicity of one time entry of unlock codes.  We also support a fast
search framework that allows new search algorithms and index files to be
added to the existing ones for improved search speed.  By using the
Sword Project as your underlying API, your software's users gain access
to the new texts constantly being added to our collection and they can
use the same texts across platforms with multiple Sword-based programs.

Sword removes much of the burden of designing new Bible software.  Most
of the underlying issues, such as search, file access, verse reference
parsing, markup format interchange, i18n/l10n, etc. have already been
dealt with, allowing you the opportunity to focus on interface design
and unique features.  And in the event that some feature of Sword does
not meet your needs, you will always have the ability to supplement it
with your own work since Sword is an open source project.

Sword offers many advanced features.  Our search engine supports regular
expression searches.  If you choose to use the optional ICU library with
Sword, you will gain access to phonetic and scholarly transliteration
facilities, Arabic shaping, Hebrew/Arabic/Syriac glyph reordering, and
other Unicode-related features.  Custom IMEs provide the mechanism for
non-Latin character input in OSes that don't support OS-wide IMEs and
provide the capability to build scholarly, technical, and phonetic IMEs
beyond what are offered by vendors such as Microsoft.  Custom
translation APIs provide the means for building l10n support in your
applications without needing to add or depend on additional 3rd party
libraries.

Sword is being built with standards compliance in mind.  Our use of
Unicode for all our data makes our engine capable of working with nearly
every language on the planet, as evidenced by our complex script Bibles
in languages such as Thai and Tamil.  Presently, Sword supports two
markup standards: General Bible Format and Theological Markup Language.
We are also working close with the Bible Technologies Group (sponsored
by ABS and SBL) to establish the Open Scriptural Information Standard,
so you know that when OSIS is completed, Sword will be the first to
support this new standard.

Sword provides a simple to use and easy to learn API.  From start to
finish, one piece of data from the Sword library can be retrieved
through Sword using a mere 3 lines of code: one to create the manager,
one to set the module, and one to request the data.  Yet the library is
complex enough to handle complex issues like hiding of footnotes,
lemmata, morphological tags, etc. and parsing of mangled verse
references with combinations of Roman and Arabic numerals.  If you ever
have difficulty using Sword, you also know that there are scores of
people willing to help, either through the developers' mailing list or
our IRC channel, including many implementers who have used the API and
those who actually coded it.  There is still work to be done on Sword,
but since it is an open project, you can contribute your time to improve
a common library used by many projects.

Building on a foundation laid by the Sword Project saves you valuable
development time and provides your users with constant module updates
and a certain base level of funtionality that they have come to expect
from all Bible software.