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