<html><head></head><body><div dir="auto">Hi Tobias,<br><br>Thank you so much for testing. My guess is that the difference is likely due to the way SWORD is compiled-- which dependencies SWORD is using. My speculation is that libcurl is probably available on Linux and your Windows build probably isn't using this library.<br><br>Can you let me know if SWORD is compiled with libcurl on your Windows build? I will try to test a Linux build without libcurl. I tried to make the new feature fallback to previous behavior if it couldn't use the new feature successfully. I obviously have failed in my backward compatibility effort. 😊 I will try to get it right.<br><br>Troy</div><br><br><div class="gmail_quote"><div dir="auto">On January 21, 2024 09:44:12 MST, Tobias Klein <contact@tklein.info> wrote:</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail"><div dir="auto">Hi Troy,<br><br>I have just done some testing with the latest changes in sword (SVN Rev. 3894).<br><br>I have not observed any issues on Linux. However, on Windows 10 the following happens:<br><br>Repository data does not seem to be returned in the same way as before (I was previously on SVN Rev. 3873, which is from November 7 2021).<br>E.g. a helper function in node-sword-interface that returns the number of modules per repository suddenly returns 0 modules for the CrossWire repository.<br><br>Is there any explanation for that?<br>I did not change anything in node-sword-interface, but only updated the sword dependency to the latest version 3894.<br><br>Best regards,<br>Tobias<br><br>On 12/16/23 11:11 PM, Troy A. Griffitts wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><div dir="auto">Hey guys,<br><br>For a while now, we've been working on a new mechanism for allowing a remote module installation repository to use only HTTPS traffic to supply their modules, if they wish. A little history and how things work in the released SWORD engine and what we have in SVN trunk now... (skip to === NEW === if you don't care about the history and why)<br><br>From the beginning of SWORD we have had as a core value the simple enabling of Bible distribution. The very first versions of our installer could use as an installation source any working installation of a SWORD library. E.g., user 1 sets up Xiphos and manually unzips 100 Bibles, commentaries, lexicons, dictionaries, etc. for use with Xiphos. User 1 can then share (network drive, USB stick, FTP) their installation folder where they have unzipped all the data for their library, and user 2 can come along and install Bibletime or Xiphos or any other SWORD application and point their installer to this shared location and install from there any Bible, commentary, lexicon, dictionary, etc., from user 1's working installation. Then user 2 can travel to their school in Zimbabwe, plug into their school's network and share their data folder from their working SWORD application and students on that network can install Bibles from them.<br><br>None of this has changed. This is still a core value and still works with all the same mechanisms.<br><br>Over the years, we have added on top of this behavior optional optimizations for remote repositories. For example, instead of looking for the mods.d/ folder and downloading individually all the .conf files found there to present to a user a list of which Bibles, commentaries, etc. are available, we first look for a mods.d.tar.gz file with all the .conf files bundled into a single download. This saves a lot of time working with large remote repositories. If we don't find this file, we still fallback to downloading the individual files. We don't want a failure to happen when passing along Bibles if this optimization is not in place, but we do want to speed things up if the manager of the remote repository knows how to manage their repository optimally and is willing to do this extra work to keep this file in place and up to date.<br><br>Over the years, the FTP protocol, which SWORD has primarily used for remote module installation over the internet, has seen data providers block traffic due to its unencrypted nature. Being Bible distributors, in most cases we don't care if anyone snoops on our data packets. Generally, again in most cases, we WANT people to snoop. We don't require user / password for distribution so the security issues involved in sending those in plain text don't apply to our applications, generally. Now, of course there are scenarios which people may wish to distribute Bibles without public knowledge, and sometimes users may wish to protect their modules with username / password credentials, and for this we have historically also supported SFTP.<br><br>One driving factor for the latest improvement described below is that we have found some mobile data providers blocking FTP traffic on their network, requiring our users to get to a WiFi connection before they can install Bibles, etc.<br><br><br>=== NEW ===<br><br>In SVN trunk there is code to handle a new facility for remote module installation. Like the optional optimization with the mods.d.tar.gz file, this new mechanism is optional. All will work as before if nothing is changed.<br><br>Fully enabling the new mechanism consists of 4 steps:<br><br>1. assuring https access to the root folder of your module repository.<br><br>2. mods.d.tar.gz is required for this mechanism to be successful.<br><br>3. module.zip files must be available from a packages/ folder at the root of your module repository folder. These .zip files have been historically required for JSword-based apps because JSword does not yet know how to install from an working installation of modules, as described at the beginning of this email. So because many of our repository maintainers support JSword, this step might be as simple as creating a packages/ -> symbolic link to your JSword .zip module files folder, if you are already maintaining zip files.<br><br>4. adding an HTTPSPackagePreference entry into our master repository list telling us the server, and path on that server, to find your repository with https<br><br><br>The main CrossWire repository now has this mechanism enabled and can be used as a reference to test frontends and can be used as an example for remote module installation repository maintainers.<br><br>For CrossWire main, #1 is available here, and at the root of this location you can also see #2 mods.d.tar.gz and #3 packages/ :<br><br><a href="https://crosswire.org/ftpmirror/pub/sword/raw/">https://crosswire.org/ftpmirror/pub/sword/raw/</a><br><br>Step 4 can be seen in our master repo list, the first entry under [Repos] here:<br><br><a href="https://crosswire.org/ftpmirror/pub/sword/masterRepoList.conf">https://crosswire.org/ftpmirror/pub/sword/masterRepoList.conf</a><br><br><br>Any SWORD app compiled against SVN trunk should now only use HTTPS when installing modules from CrossWire main.<br><br>May I ask to please test and give feedback? Thank you for all the advice and encouragement to add this functionality. I pray this enhances our ability to distribute more Bibles to those who have yet to hear the Good New of Jesus Christ and to be used by Him to build up His church,<br><br>Troy<hr>sword-devel mailing list: sword-devel@crosswire.org<br><a href="http://crosswire.org/mailman/listinfo/sword-devel">http://crosswire.org/mailman/listinfo/sword-devel</a><br>Instructions to unsubscribe/change your settings at above page<br></div></blockquote><div dir="auto"><hr>sword-devel mailing list: sword-devel@crosswire.org<br><a href="http://crosswire.org/mailman/listinfo/sword-devel">http://crosswire.org/mailman/listinfo/sword-devel</a><br>Instructions to unsubscribe/change your settings at above page<br></div></pre></blockquote></div><div dir="auto"><div class='k9mail-signature'>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</div></div></body></html>