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
Thank you to each one who responded with a font suggestion. I have
bundled 3 suggestions.
There are two new options under Settings which should allow you to
selects a font for both the reading text and also the application text.
I first list all the bundled fonts, then 3 generic font families,
Thank you for the report, Br. Cyrille. It is fixed in the next release.
On 3/20/20 6:28 AM, Cyrille wrote:
> Have a look in the Chinese locale, it display zh_CN and note Chinese (in
> chinese).
>
> Le 20/03/2020 à 05:18, Daniel Owens a écrit :
>> Not sure if I love it, but Google's Noto fonts
:)
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,
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
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
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
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
On Fri, Mar 20, 2020 at 2:25 PM Michael Johnson 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
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
when using ftp,
On Fri, Mar 20, 2020 at 11:29 AM David Haslam wrote:
> Thank you Caleb for so succinctly expressing the point that I vaguely
> hinted at.
>
> This is something that needs our urgent attention.
How does it need our attention? We have supported HTTP and HTTPS for a very
long time for any
I disagree.
I never use my browser for FTP and I don't want security for the files I
transfer over FTP. It's a waste of bandwidth and cycles.
HTTPS doesn't provide a common means to discover and traverse file
systems like FTP. WebDAV over HTTPS would be the alternative.
SFTP would be our
I don't know how you use FTP, but I have used SFTP for quite some time now and
don't miss FTP at all for transferring to/from web servers. In Linux I just use
the file manager (Nemo/Dolphin/Thunar) and it is seamless
On 3/20/20 11:28 AM, David Haslam wrote:
Thank you Caleb for so succinctly
Thank you Caleb for so succinctly expressing the point that I vaguely hinted at.
This is something that needs our urgent attention.
David
Sent from ProtonMail Mobile
On Fri, Mar 20, 2020 at 16:23, Caleb Maclennan wrote:
> I don't think code sharing code with browsers is even the issue here,
I don't think code sharing code with browsers is even the issue here, the
issue is the FTP ecosystem is going away — and surprising quickly for
something that used to be so ubiquitous. I've already bumped into several
ISP's just flat out blocking all FTP traffic, probably because they didn't
know
On Fri, Mar 20, 2020 at 2:20 AM David Haslam wrote:
> The writing is on the wall for FTP.
>
> Firefox to remove support for the FTP protocol | ZDNet
> https://flip.it/AY-TTt
>
> How will this trend affect how we design and communicate?
>
Since we don't use or rely on Mozilla or Chrome code, I
Have a look in the Chinese locale, it display zh_CN and note Chinese (in
chinese).
Le 20/03/2020 à 05:18, Daniel Owens a écrit :
> Not sure if I love it, but Google's Noto fonts are designed to handle
> many different languages. Noto Serif would not be a bad choice. We use
> it to publish books
The writing is on the wall for FTP.
Firefox to remove support for the FTP protocol | ZDNet
https://flip.it/AY-TTt
How will this trend affect how we design and communicate?
Best regards,
David
Sent from ProtonMail Mobile___
sword-devel mailing list:
18 matches
Mail list logo
