I think Troy, the concern is correct. For the publisher with some decent IT muscle and budget a proper repo must be better, but for the small town church with a website and a couple of modules to share - zip and http is a must.
Having a multiplicity of methods of getting modules into the system would certainly be easier. My preference: 1) keep current methods - it is best for huge numbers of modules and it is probably also best for anyone with enough money to have a fixed ip and a server, able to run anonymous ftp 2) add methods for local installation of zips. Look at MK Bible - pull a zip over the programme and it gets installed. This is - emphatically - not how I would want to install a large selection of modules or how I would want to publish the same, but it is probably the best usability i have seen for a frontend using only 2-3 modules (which is what MKBible is laid out for) and a small time publisher or someone who has target audience of little computer literacy Peter > Von: ad...@bible.salterrae.net > An: "SWORD Developers\' Collaboration Forum" <sword-devel@crosswire.org> > Betreff: Re: [sword-devel] Remote Module Repository Wiki > > 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. > > I don't think that installing an FTP server is trivial. > I can't agree that 'most hosting services provide FTP access.' > > Most cheep hosting services provide ftp access only for its maintainer, > ftp access is not permitted for public use. > HTTP services are name-based , FTP services are IP-based. So > if one want to service an FTP server, one must own one IP address > for it, contrary to the fact that many HTTP services can share one > IP address. > > Furthermore FTP service needs two connections , one for control and > one for data. one is outgoing, another is incoming. this make > firewall rules very complexing. > Servicing an HTTP server is easy, and servicing an FTP server is annoying. > If both methods can serve same jobs, I would rather choose HTTP . > > > > > 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: > > > > -- > ad...@bible.salterrae.net > > > _______________________________________________ > 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 -- GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl _______________________________________________ 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