:) 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