[sword-devel] Remote Module Repository Wiki

[Troy A. Griffitts]

I do understand the very real practical concerns about FTP you point
out, but we have practically received almost no support emails from
users not being able to install because FTP was blocked.  Most hosting
services provide FTP access.  The issue we ran into before was some
didn't provide anonymous ftp access, which we've rectified by adding
username / password fields in our repository registry and support for
this in our installer, and in reality to install an FTP server on a
windows box is trivial compared to the ongoing maintenance of assuring
zips are created and placed in the correct folder, an index file for the
zips is created and kept updated whenever anything changes, etc.

It might seem trivial to us, and might actually be trivial for the
publishers, in practice (and might eventually be how we end up going if
we do find real roadblocks with our current FTP mechanism), but:

It sure is easy to sell: "just get your library of books installed and
working in any of our frontends, and then point an FTP server to that
installation and you are now publishing your own remote repository; drop
that installation onto a CD or USB stick and you can use that media as
an install source with any of our frontends; drop it to a network drive
and you can use that as an install source for any of our frontends..."
(I realize the last 2 don't have anything to do with the FTP issue at
hand, but it goes along with the general idea of making it really easy
for anyone to share their library with others in most any setting)

Or, "you currently have 100+ of your Bibles formatted as SWORD modules
you are publishing from your server via SWORDWeb.  All you have to do is
point an FTP server to this same data path and you are now publishing
your 100+ Bibles for use in all of our software on any of our supported
platforms: Windows, Linux, Mac, iPhone, Android, etc."


These are real world cases right now.

And the most important thing for us is to have a unified message to the
publishers, that all of our software can install from a common
repository format.

Again, I'm not amiss to requiring zips and an index file if we find it
necessary, but if it is not necessary, I would rather us do alot of
extra work to make life even the slightest bit simpler for anyone who
wishes to make their materials available.

And also, as said to the JSword team, I'm not opposed to them having
their own mechnism they feel is better, but I only ask that it is
optional-- in the sense that, failing to locate their own mechanism on a
remote repository, they fall back to the common FTP mechanism.


Hope this communicates that I understand the concerns and have
considered them and made what I hope we can at least agree is a good
solution, if not the best in your mind.

Troy





 .but the fact of the matter is that FTP is the Internet protocol for
browsing a tree of files and for transferring those files

On 11/05/2010 01:09 AM, Matthew Talbert wrote:
> I know this has been an area of disagreement in the past, and I'm not
> intending to start any sort of argument, but just share my experience.
> Among the businesses I work with (mostly small operations), there is
> almost no familiarity with FTP at all, and in many cases (in the
> larger ones), FTP is often blocked both incoming and outgoing. Many of
> these are Windows environments with IIS for a web server. Looking at
> the skills of these organizations and their IT departments, setting up
> an FTP server would not be the ideal choice of deployment. Especially
> when it comes to things like mods.tar.gz which require tools outside
> their normal tool range. A much more ideal repository format for these
> types of organizations, would be that used by jsword. It just requires
> a simple HTTP-accessible directory, in which a bunch of zip files are
> dropped. Ideally there would be one file with a list of what's
> available.
> 
> Again, I'm not arguing what should be done, or even what is the most
> common setup, but in my experience the current requirements of setting
> up a repo with FTP would not be the ideal solution for people with
> little IT experience. And as we have discussed before, it is difficult
> to find good FTP hosting on the web, and challenging for users to set
> up. It is much simpler and cheaper to find HTTP hosting.
> 
> I know we now can access repos over HTTP, but it seems to me quite
> fragile. It depends on Apache's directory listing, and even running it
> through Squid (or other proxy servers) completely breaks it. I haven't
> tried it, but I suspect using IIS would completely break it as well,
> as it has a different directory listing.
> 
> So, our repo setup guidelines are not really very simple at all, but
> pre-suppose a wide variety of things like "client and server must not
> be behind proxies", "client and server must have FTP ports open",
> "server must be running apache for HTTP access", and so on. I'm afraid
> these sort of requirements are going to cause difficulties in getting
> other organizations set up, if they have IT departments and
> environments anything like what I see daily.
> 
> Matthew
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page