To outline the supported logic for SWORD module installation as it
currently stands:
The SWORD Project library, as of 1.6.0 currently has builtin features to
support:
o Management of an existing SWORD library installation
(provided the user has proper permissions to perform the actions, etc.)
deleting, listing, comparing to another library installation to look for
updates/additional modules, etc.)
o Installation of modules from another existing SWORD library
installation via file path (e.g., Z:\The SWORD Project\; /mnt/cdrom/)
this is useful for installing from another SWORD installation made
available by sharing a windows drive, an organization network drive, a
CD, DVD, USB stick, mem card, or any other way standard filesystem
access can be obtained to another SWORD installation.
o Installation of modules from another existing SWORD library
installation via FTP ( e.g., ftp://crosswire.org/pub/sword/raw )
o (NEW IN 1.6.0) Auto-discovery of new locations for the previous.
This is done by querying the master list of known module repositories
available here:
ftp://ftp.crosswire.org/pub/sword/masterRepoList.conf
These are currently the officially supported methods of module
management in The SWORD Project library.
Due to the release of the new auto-discovery features in 1.6.0, I
believe all frontends should expose each of these features as a minimum,
so we can have a base set of common installation means across all of our
applications.
This gives us a unified message going forward to publisher who wish to
make their content available.
=====================
Now, having said this, I think it's exciting that other projects add
their own methods catering to their user groups.
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
interface.
======================
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
repository.
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.
In conclusion, we need to have, for content creators, a very low level
of effort entrance into the hosting of SWORD modules ("do your modules
work in your favourite SWORD application? Great, drop your working SWORD
module installation onto a CD", "point an FTP server to your working
SWORD module installation", (maybe future) "point an http server to your
working SWORD module installation" "-- and oh, by the way, here are
some steps you can take to speed up downloads for your users, but they
aren't required").
We need to support these most basic installation means commonly across
our applications.
sword::InstallMgr provides support for these, so C++ frontends can make
calls to this class to support these methods-- I believe most already do.
Unfortunately and obviously, JSword cannot depend on sword::InstallMgr
providing this functionality for them and it will take effort to bring
JSword-based apps up to supporting this common set of methods. I always
appreciate the effort the JSword teams makes to continue to walk in step
with the C++ side of things-- often implementing their own methods which
seem better in their eyes, but continuing their commitment to strive to
support _at least_ (tongue in cheek) the C++ lead.
-Troy.
DM Smith wrote:
On May 13, 2009, at 11:50 PM, Jonathan Morgan wrote:
On Thu, May 14, 2009 at 11:07 AM, Daniel Owens <dhow...@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
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
