[sword-devel] Why Sword?

[Lloyd N. Landers, Jr.]

Chris,

Thanks for providing this historical and strategic perspective for The 
Sword Project.  It is always neat for newbies like myself to know from 
whence things came (one of the reasons we have the first couple of chapters 
of Genesis, right?)

This is a really neat project and I feel grateful and privileged to have 
even a very small part in it.

May God bless those of you who are really doing all the work.

Lloyd

At 01:58 PM 2/9/2002 -0800, you wrote:
>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.