chrislit at crosswire.org
Thu May 14 10:19:29 MST 2009
Troy A. Griffitts wrote:
> I would like to add new officially supported methods, like adding:
> o Installation of modules from another existing SWORD library
> installation via HTTP ( e.g.,
> http://crosswire.org/ftpmirror/pub/sword/raw )
> A skeleton class for this method was already added in 1.6.0 so we can
> shoot to implement this in the 1.6.x branch without changing the API
> Aside from the officially supported methods of installation, there are
> caching methods we implement to assist in optimizing installation, e.g.
> if we find a mods.d.tar.gz file at the root of the 'other' SWORD library
> installation from where we're installing, we'll copy and untargz this to
> discover which modules are available, instead of copying each
> mods.d/*.conf file one at a time.
> **** BUT THE IMPORTANT THING HERE in my mind, is that, while we have
> caching mechanisms in place, and while we might even add more
> (hypothetically, a zips/ folder at the root of the 'other' SWORD library
> installation where we can check for a pre-zipped module archive so we
> can avoid downloading module data files and images one at a time, and
> other methods)...
> .... THE VERY IMPORTANT THING NOT TO MISS HERE.... (have I focused the
> attention of skimmers yet? :) )
> ... is that these are EXACTLY THAT: CACHING/OPTIMIZATION features.
> *** NOT *** required features to make a valid repository SWORD module
> A frontend should NOT depend on these features being available. If they
> exist, use them-- great! If not, please support the minimum common
> installation features outlined above.
Specifically with reference to the way JSword deals with module
downloading: I really look forward to seeing a shift from use of the
cached ZIPs to using the FTP site (via HTTP if necessary).
Greater than 99% of the time, the ZIPs will be fine, but there will be
occasional problems. One is simply that their use requires an extra
step, which very occasionally fails. We had some problems after the
server upgrade, where new ZIPs couldn't be created, which would have
affected JSword users and went unnoticed until someone downloading one
of the affected ZIPs from the webpage noticed and alerted us.
The (to my mind) greater issue is simply that it this system requires
someone else to have already downloaded the most recent version of a
module. The ZIPs are only created by the download servlet. Assuming our
hope that people migrate to InstallMgrs comes true, fewer and fewer
people will download ZIPs from the webpage, making it progressively less
likely that the correct ZIP exists.
More information about the sword-devel