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

Greg Hellings greg.hellings at gmail.com
Fri Mar 20 20:32:05 EDT 2020 

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 <scribe at 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 <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
> >
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20200320/1baf663d/attachment-0001.html>

More information about the sword-devel mailing list