[sword-devel] feature request: module manager enhancement

[DM Smith]

On May 13, 2009, at 11:50 PM, Jonathan Morgan wrote:

> On Thu, May 14, 2009 at 11:07 AM, Daniel Owens <dhowens at pmbx.net>  
> wrote:
>> You've got my vote. It seems to be an understandable confusion that  
>> zipped
>> modules are available but most front-ends don't support their use.  
>> BPBible
>> implemented the installation of modules using zipped archives, and it
>> doesn't even have the standard module manager yet. That to me says  
>> that this
>> feature is easy to implement (and in my thinking long overdue). HTTP
>> repositories are another MAJOR motivation for me too...
>
> A related problem is the number of different zip formats.  Currently,
> Crosswire has RawZip, Windows Zip (which is just intended for BibleCS,
> IIRC) and Mac OS X (which I'm not sure is really still supported by
> MacSword).  BPBible theoretically supports both Windows Zip and Raw
> Zip, but I think Raw Zip is probably a better format (being at least
> in theory application independent) and we have had a couple of bug
> reports installing the YLT, which I haven't been able to reproduce
> either with Win Zip or Raw Zip.  I would really prefer us to offer
> just the one format (Raw Zip) unless there is a very good reason not
> to, since that saves the need for users to have to make a choice.  If
> we do have multiple formats then I think the wording needs to change
> (currently it is "Windows users should click on the link in the
> WINDOWS column, while Linux users should click on the link in the RAW
> Zip column.").

I think the windows zips are problematic except for those using The  
SWORD Project for Windows (aka BibleCS) and sometimes even for those.

The "windows" zip contains an Install Shield installer which stages  
the module at c:\Program Files\CrossWire\The SWORD Program\newmods.  
When the user starts BibleCS, a dialog comes up, stating "Found New  
Module", giving the Description and the About from the module's conf.  
For most modules, the dialog's text is truncated. For each module  
installed this way the dialogs come up one after the other upon  
closing the prior.

This mechanism silently fails if BibleCS is not installed to the  
default location or if BibleCS is not installed at all. It also fails  
to work when BibleCS is installed but not used as Bible Desktop,  
Xiphos, Alkitab, and all others running on Windows won't look there  
and don't have the mechanism to work that way.

IIRC, Troy said that we had (may still have) an agreement with a  
copyright holder to show the About info to the end user. (Correct me  
if I am wrong.)

Personally, I think the zips, other than the raw zips should be done  
away with. I think Manfred said the Mac zips can go away on the  
download page, though he won't be removing support for them in  
MacSword. The Windows zips may have been a good idea at the time. I  
think that there are other ways to notify the user that new modules  
have been installed external to the program's module installer. And it  
would be something good for all of our front-ends.

Regarding installation of module zips, I think there are two issues  
here:
1) Install of zips that are on the user's local machine.
2) Install Manager download of zips via ftp or http.

Regarding 1). I think this is a great idea. I also like the "drag it  
onto the app to unzip" approach that David Haslam mentioned. The  
mechanism should be part of the SWORD library. And Manfred's  
implementation that if the zip is found in the same folder as mods.d  
and modules, it will be automatically unzipped.

For JSword, we have planned the ability to specify a zip by URI, which  
could be of the file:// type. A JSword front-end could then provide a  
local file system browser to help the user find the zip.

Regarding 2), Troy has told me that JSword's http implementation to  
download raw zips is not a supported SWORD mechanism and might go away  
or change at any time. We are taking that risk as we had too many  
problem reports regarding our FTP mechanism (e.g. WinXP blocks it,  
doesn't work behind firewalls or proxies, ...)

Troy has agreed that the SWORD ftp mechanism can look for the zips  
first and failing that do the current behavior, with zips being a  
cached representation. And that ftp might be able to be taught to  
generate the zip on request.

In Him,
	DM