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: [email protected] > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
