[sword-devel] BibleCS Installer: SWORD_PATH

[L.Allan-pbio]

> L.Allan-pbio wrote:
>> (something I'm unclear about .... does JSword use the C++ api in some 
>> manner of "binding", or does it have an independent "reversed engineered" 
>> api written in Java?)
>>
> JSword does not use any C++. It is pure Java. It also does not call any 
> executables, such as InstallManager.exe.

Interesting .... I suppose I ought to install JSword and get more familiar 
with it.

Is there an expectation from CrossWire that JSword implement a very faithful 
"reverse engineering" of the C++ sword-api? How much flexibility and degree 
of allowed incompatability have you found to be the case, if any?

I'm especially curious about what kind of search performance you experience. 
That is VERY CPU intensive. Does JSword implement an architecture of filters 
that is strict or relaxed as far as compatibility with the C++ sword-api? 
My understanding is that Lucerne is Java based, wth CLucerne based on it. 
Does JSword use Lucerne?

> JSword has two notions concerning modules:
> It has a module path which is the set of all locations which it could 
> understand as having modules.
> It also has an install directory where it maintains modules. This defaults 
> to ~/.jsword. The install directory is maintained as the first directory 
> on the module path.
> The user can change either of these.
> Currently, we only have one install directory, but our design calls for 
> having one per install site (e.g. stable, beta, CD, etc)

I've gotten somewhat familiar with what happens with SWMgr and how it 
resolves which resources are available. My experience is that it can be a 
significant bottleneck to getting an application "launched" on an older 
computer. (LcdBible has a "target niche" of obsolete computers such as what 
3rd world missionaries would have, and uses a background thread for SWMgr to 
expedite "getting the show on the road.") Does JSword implement a strictly 
compatible or relaxed compatible version of SWMgr and associated classes?

> It handles duplicate modules on several paths by finding the first one 
> along the module path.
> Only modules in the install directory can be deleted, since this is 
> assumed to be under the management of JSword.