[bt-devel] BibleTime's Goals (was Re: New passage selector proposal)

[Greg Hellings]

OK, I'll bite. :)

On Thu, Apr 19, 2012 at 11:12 PM, Troy A. Griffitts
<scribe at crosswire.org> wrote:
> Just a quick comment. I say this once every 3 years or so, but...
>
> Of course my opinion is that you are making a huge mistake trying to
> abstract the SWORD code away and not use the classes directly in your
> frontend.
>
> The classes in SWORD were written to facilitate quick and easy frontend
> development. As Jaak notes, your abstractions are not well organize. BT
> seems to chronically reimplement SWORD functionality for no real benefit,
> e.g.,
> BTStringMgr to use Qt Unicode functions instead of ICU

ICU is optional in SWORD. Without it that functionality is not
available. By implementing it with Qt - which will always be available
in places that BibleTime goes - we can always have ICU-like
functionality available.

> Replacement for CurlFTPTransport to use Qt instead of curl

See previous comments which apply here as well.

> Your own lucene impl instead of the builtin SWORD search engine.

The story as it has been told me claims that not all fields of SWORD's
data are searchable with SWORD's Lucene implementation. BibleTime's
implementation supposedly allows more fields to be specified. Maybe
this was a misperception on BibleTime's earlier developers or maybe it
has been changed in SWORD or maybe I was told a tall tale. But that's
the reason.

> Reimplementations of all the HTML filters in SWORD.

The ones I have seen are extensions of SWORD's filters, not
reimplementing it. BibleTime had a unique display engine at one time.
The filters haven't been changed much (if at all) since then. But it
also displays some things in a very different way than e.g. Xiphos
does. BibleTime allows our users to create their own CSS stylesheets,
and we display parallel versions in vertical tabular columns. For that
it needs modified HTML from what other frontends might require.

>
> Are you partners in software development with CrossWire or just using SWORD
> to get access to our module library?

Pejorative and leading questions are unnecessary.

>
> If you really feel you have a need which isn't handled by the engine,
> wouldn't you rather like to contribute code back to the engine for other
> frontend projects to use, and take advantage of the numerous improvements
> other projects have contributed to these things?

BibleTime is GPL. Anyone is welcome to see and take our code and
modifications either into their application or back into SWORD.
BibleTime simply isn't willing to wait for something to get pulled
into SWORD and then wait for a new release to be made when we can
already do what we want. No one on our team is willing to go into the
engine like Karl is or Chris or DM, so when we need or want a change
or improvement we do it ourselves in BibleTime.

>
> I always hear the argument that you want to add other data sources in the
> future, or completely replace SWORD in the future. Why? Are we a body
> working together, building common tools, sharing together, or do you only
> take what we're offering?

This is a false dichotomy. Adding in the ability to draw from a source
like the Perseus Tools or read a general e-book from Gutenberg does
not mean incompatibility with SWORD if implemented properly. I haven't
heard anyone saying that SWORD ought to be completely replaced in
BibleTime, only that we want to not require SWORD as a direct
dependency while simultaneously expanding what our users have access
to. SWORD is the premier source of free Bible texts but it isn't the
only good source of texts. And some things from e.g. Perseus are
valuable not only for the texts that they contain but their
functionality to parse classical languages in their original or
transliterated forms.

>
> ;) Just wanted to rile up conversation. :)
>
> Troy
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.

The fact that the current code is not well organized to make such
abstractions and expand the feature set reflects that this wasn't even
a goal when the current application was written. It doesn't reflect
that we should just use what SWORD has when our desire is to be able
to expand beyond just SWORD as a source of materials and features.

A second reason, not addressed above, that BibleTime wants to abstract
apart multiple layers is to permit sharing of more code across GUIs.
Qt is diverse enough (versions available that work on Windows, OS X,
Linux, Symbian, Android, Windows Mobile, MeeGo, iPhone, WebOS, Kindle,
Blackberry and more) that if BibleTime can be split into at least two
portions - the abstraction layer that wraps SWORD and the GUI - then
anyone could use Qt to develop a custom GUI on top of our work for
that platform. This is our second hope with our abstraction work.
There are already people who are using BibleTime as a base to create
mobile-centric apps. If we can properly do this work then we can
facilitate their efforts and possibly encourage others.

--Greg