
<html><head></head><body>So, in summary, you don't consider yourselves part of the CrossWire developer community? None of the things you've mentioned has been realized in 20 years, SWORD is practically a direct dependency, and if you would like access to Perseus, wouldn't it be better to put in the effort to make Perseus (and SWORD data) available through a well thoughtout Bible research framework instead of your patchwork backend you've lived with for 20 years because of 'in principle' arguments?<br>

SWORD is designed as a backend for Bible research software, with a modular architecture (as seen by your many reimplementations; just because you _can_ do something doesn't necessarily mean you _should_) allowing plugins to access different data sources and in different markups. If you think you can design a better class heirarchy, you may be right, but why? Is SWORD really so different than what you would design yourselves as a backend? Is it always 'do it ourselves', and 'differentiate from the other CrossWire projects' or are you willing to share your improvements with the community as you have used our work for the entire life of your project?<br>

-- <br>

Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br><br><div class="gmail_quote">Greg Hellings <greg.hellings@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif">OK, I'll bite. :)<br /><br />On Thu, Apr 19, 2012 at 11:12 PM, Troy A. Griffitts<br /><scribe@crosswire.org> wrote:<br />> Just a quick comment. I say this once every 3 years or so, but...<br />><br />> Of course my opinion is that you are making a huge mistake trying to<br />> abstract the SWORD code away and not use the classes directly in your<br />> frontend.<br />><br />> The classes in SWORD were written to facilitate quick and easy frontend<br />> development. As Jaak notes, your abstractions are not well organize. BT<br />> seems to chronically reimplement SWORD functionality for no real benefit,<br />> e.g.,<br />> BTStringMgr to use Qt Unicode functions instead of ICU<br /><br />ICU is optional in SWORD. Without it that functionality is not<br />available. By implementing it with Qt - which will always be available<br />in places that BibleTime goes - we

can always have ICU-like<br />functionality available.<br /><br />> Replacement for CurlFTPTransport to use Qt instead of curl<br /><br />See previous comments which apply here as well.<br /><br />> Your own lucene impl instead of the builtin SWORD search engine.<br /><br />The story as it has been told me claims that not all fields of SWORD's<br />data are searchable with SWORD's Lucene implementation. BibleTime's<br />implementation supposedly allows more fields to be specified. Maybe<br />this was a misperception on BibleTime's earlier developers or maybe it<br />has been changed in SWORD or maybe I was told a tall tale. But that's<br />the reason.<br /><br />> Reimplementations of all the HTML filters in SWORD.<br /><br />The ones I have seen are extensions of SWORD's filters, not<br />reimplementing it. BibleTime had a unique display engine at one time.<br />The filters haven't been changed much (if at all) since then. But it<br />also displays some things in a very

different way than e.g. Xiphos<br />does. BibleTime allows our users to create their own CSS stylesheets,<br />and we display parallel versions in vertical tabular columns. For that<br />it needs modified HTML from what other frontends might require.<br /><br />><br />> Are you partners in software development with CrossWire or just using SWORD<br />> to get access to our module library?<br /><br />Pejorative and leading questions are unnecessary.<br /><br />><br />> If you really feel you have a need which isn't handled by the engine,<br />> wouldn't you rather like to contribute code back to the engine for other<br />> frontend projects to use, and take advantage of the numerous improvements<br />> other projects have contributed to these things?<br /><br />BibleTime is GPL. Anyone is welcome to see and take our code and<br />modifications either into their application or back into SWORD.<br />BibleTime simply isn't willing to wait for something to get

pulled<br />into SWORD and then wait for a new release to be made when we can<br />already do what we want. No one on our team is willing to go into the<br />engine like Karl is or Chris or DM, so when we need or want a change<br />or improvement we do it ourselves in BibleTime.<br /><br />><br />> I always hear the argument that you want to add other data sources in the<br />> future, or completely replace SWORD in the future. Why? Are we a body<br />> working together, building common tools, sharing together, or do you only<br />> take what we're offering?<br /><br />This is a false dichotomy. Adding in the ability to draw from a source<br />like the Perseus Tools or read a general e-book from Gutenberg does<br />not mean incompatibility with SWORD if implemented properly. I haven't<br />heard anyone saying that SWORD ought to be completely replaced in<br />BibleTime, only that we want to not require SWORD as a direct<br />dependency while simultaneously expanding

what our users have access<br />to. SWORD is the premier source of free Bible texts but it isn't the<br />only good source of texts. And some things from e.g. Perseus are<br />valuable not only for the texts that they contain but their<br />functionality to parse classical languages in their original or<br />transliterated forms.<br /><br />><br />> ;) Just wanted to rile up conversation. :)<br />><br />> Troy<br />> --<br />> Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br /><br />The fact that the current code is not well organized to make such<br />abstractions and expand the feature set reflects that this wasn't even<br />a goal when the current application was written. It doesn't reflect<br />that we should just use what SWORD has when our desire is to be able<br />to expand beyond just SWORD as a source of materials and features.<br /><br />A second reason, not addressed above, that BibleTime wants to abstract<br />apart multiple layers

is to permit sharing of more code across GUIs.<br />Qt is diverse enough (versions available that work on Windows, OS X,<br />Linux, Symbian, Android, Windows Mobile, MeeGo, iPhone, WebOS, Kindle,<br />Blackberry and more) that if BibleTime can be split into at least two<br />portions - the abstraction layer that wraps SWORD and the GUI - then<br />anyone could use Qt to develop a custom GUI on top of our work for<br />that platform. This is our second hope with our abstraction work.<br />There are already people who are using BibleTime as a base to create<br />mobile-centric apps. If we can properly do this work then we can<br />facilitate their efforts and possibly encourage others.<br /><br />--Greg<br /><br /><hr /><br />bt-devel mailing list<br />bt-devel@crosswire.org<br /><a href="http://www.crosswire.org/mailman/listinfo/bt-devel">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br /></pre></blockquote></div></body></html>