[sword-devel] Firefox to remove support for the FTP protocol | ZDNet

Fri Mar 20 18:26:33 EDT 2020

:)

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 <Michael at ebible.org <mailto:Michael at 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 at crosswire.org <mailto:sword-devel at 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 at 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 at 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 at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>