It's worth noting that cURL supports SFTP/SCP natively already. Adding support for SFTP in a cURL enabled SWORD build should be fairly easy. I seem to recall messing around with that ages ago when HTTP and HTTPS were added. But it suffered limitations as I mention below.
The problem with that is SFTP is not like FTP in that it does not innately understand an anonymous read only user. Getting a system into that state is rather a bit of a hack. I'm going to work up an automated set of configure scripts to see if it works, these days, but it's not as easy as it is in FTP. --Greg On Fri, Mar 20, 2020, 17:27 Troy A. Griffitts <scr...@crosswire.org> wrote: > :) > > The primary use case we have today for remote repositories, where no > SWORD applications are involved (and thus would not benefit from SWORD > creating folder and file index snapshops), are 3rd party publishers (and > 2nd and 1st party publisher: us) who manage their module folders by hand. > > IMO, we shouldn't create static meta files for information which can be > retrieved dynamically. It creates a point for inconsistency and this > should generally be avoided. i.e., we shouldn't try to create static > files which describe our dynamic file system where users change things > all the time. Especially when there are protocols we can and do use > which provide that meta information to us. In my experiences points for > inconsistency become maintenance nightmares for everyone who is asked to > keep them current. > > As a point of reference: > > We currently have 1 optional dynamic item added to our repositories: > InstallSize > > I hate this option. I hear complaints often that this or that script > didn't update the .conf files or that some publisher didn't add the > InstallSize option to their .conf files. It's optional, so no Bibles > are prevented from being distributed if it's not present. > > I was never in favor of adding this option, but it provided what others > saw as a user experience improvement and I hadn't given them a way to > obtain it dynamically. The details are that InstallMgr just grabs conf > files from the remote repository at first; it doesn't traverse any other > folders until a module is asked to be installed. I could provide in > SWORD a quick method to dynamically compute and return the install size > of a remote module on demand and should eventually do this so we can > eternally ban the InstallSize conf parameter, but I just haven't had it > high on my priority list). We have like 3 modules out of 2000 which are > huge and which I would be interested to know they were huge before > install, but 99.9% of our modules are all between 1MB and 8MB, which is > smaller many photos these days and InstallSize provides no useful > information for these. Maybe we should simply include a > LargeModule=true option for the 3 which are the outliers and be done > with it. > > But, anyway, these are all theoretical arguments and good to toss > around. There is no current problem with this we are trying to solve > right now, and I am sure, like you, have a backlog of Bible objectives > on my todo list. > > I can see a motivation you may have with ebible.org, to remove the FTP > service from your server. I wouldn't be against adding to SWORD an > optional check for a meta file in the HTTP drivers and using that if the > repository manager wishes to provide it, but I'd still like to not give > up a line I regularly use with our publishers, "Setting up a remote > module repository is easy. Simply take any working SWORD library and > point an FTP server to it." My motivations are only to make it as easy > as possible for others to use SWORD to share the Scriptures. I am sure > yours are the same. > > Troy > > > On 3/20/20 2:46 PM, Michael Johnson wrote: > > On 3/20/20 11:32 AM, Troy A. Griffitts wrote: > >> Yes, we could do that, but... > >> > >> that's the comment I tried to make earlier. FTP (and SFTP and WebDAV) > >> doesn't require any meta information-- it dynamically provides this for > >> you from looking at the files in your filesystem. > >> > >> If we require each of our repositories to setup a special file before > >> they can be used by our applications, we have at least 2 regressions: > >> > >> 1) Any working SWORD library is not, by definition a valid repository > >> for install. i.e., 3rd parties or normal users have work now to make > >> their installed SWORD library available for other to install from. > > Unless we upgrade the Sword library to automatically index the current > installation, refreshing that index when appropriate. > > > >> 2) We are now trying to delivery information about a filesystem that we > >> get dynamically from file transfer protocols (FTP, SFTP, WebDAV) and > >> there is a huge potential for inconsistencies between what is in our > >> static metadata file and what is actually on the filesystem. > > Unless we upgrade our Sword library to automatically index the current > installation, and when appropriate, the repository. > > > > FTP is dying. Let it go. > > > > > >> It would be certainly be an improvement though when parsing folder and > >> file information over HTML (and not using WebDav). > >> > >> Troy > >> > >> > >> > >> On 3/20/20 2:13 PM, Michael Johnson wrote: > >>> Wouldn't it make more sense, going forward, to make a directory file > in a standard (for us) format on each repository? > >>> > >>> On 3/20/20 9:40 AM, Troy A. Griffitts wrote: > >>>> Right, the issue is that our HTTP support is implemented as an > attempt to parse Apache directory listing HTML output. It almost certainly > won't work with other web servers and Apache has already changed their > output on us at least once. > >>>> > >>>> Nick (PocketSword) graciously provided the original support when he > was having trouble with FTP access over iOS. > >>>> > >>>> Bishop uses SWORD's FTP support over iOS with no issues that I've had. > >>>> > >>>> It could have been a network provider filtering out FTP traffic when > Nic was doing development. Not sure. > >>>> > >>>> This is one real world advantage to having another protocol > available: if network providers babysit their users and try to filter their > data for them (which would tick me off if my provider did that). > >>>> > >>>> Troy > >>>> > >>>> > >>>> On 3/20/20 12:31 PM, Greg Hellings wrote: > >>>>> On Fri, Mar 20, 2020 at 2:25 PM Michael Johnson <mich...@ebible.org > <mailto:mich...@ebible.org>> wrote: > >>>>> > >>>>> On 3/20/20 7:44 AM, Greg Hellings wrote: > >>>>> > > >>>>> > ✔ https://www.crosswire.org/ftpmirror/pub/sword/ > >>>>> > ✔ http://ftp.bible.org/ > >>>>> > ✗ http://ftp.xiphos.org/ > >>>>> > ✗ http://ftp.ibt.org.ru/ > >>>>> > ✗ https://ftp.ebible.org/ > >>>>> Please note that https://ebible.org/sword/ works. You should > use ftp.ebible.org <http://ftp.ebible.org> when using ftp, and just plain > ebible.org <http://ebible.org> when using http or https. > >>>>> > >>>>> > >>>>> Ah, there it is. I missed that entry in the wiki page. Indeed. > >>>>> > >>>>> --Greg > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> signature > >>>>> > >>>>> Aloha, > >>>>> */Michael Johnson/** > >>>>> 26 HIWALANI LOOP • MAKAWAO HI 96768-8747*• USA > >>>>> mljohnson.org <http://mljohnson.org> <http://mljohnson.org> • > Phone: +1 808-333-6921 • Skype: kahunapule > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> sword-devel mailing list: sword-devel@crosswire.org <mailto: > 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 > >>>> _______________________________________________ > >>>> 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 > > > > _______________________________________________ > 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