Re: Creating a "SWORD-over-network" protocol for remote SWORD repo access?

On 29.07.24 07:08, Greg Hellings wrote:
> The goal for a repository is to support the simplest methods of access.
> Especially to support access by people who have no network so that an
> entire repository can be loaded directly onto a CD, DVD, USB stick, or
> other external media and passed around. Libsword can then install directly
> from that. FTP was first implemented because it allowed the same super
> simplistic process of pointing an FTP server at a working repository and
> then anyone who can access that FTP server can also access and install
> modules from there.
> 
> The goal of repository access and installs is not to create or define a
> standard. It is, rather, to have the very simplest and easiest access
> possible. Others have come through and implemented some parsing for the
> HTML served up over HTTP/HTTPS which can be used if libsword is compiled
> with the optional libcurl support. When I first helped contribute to those
> code bases they strove to support both the Apache and Nginx form of HTML
> that was served up by the automatic indexing those servers offer. Again,
> the goal was not to provide cryptographic security, it was not to sign
> files, it was not to define a standardized server process, or use some more
> robust standard like WebDAV or what have you. The goal was simplicity.
> Initially to allow iPhone users access to remote repositories while on cell
> networks where FTP was blocked by many carriers and possibly the device
> itself to some extent. Again, the goal was simplicity of access - pointing
> the root of a folder to a working repository installation would allow
> someone to remotely access all of the resources on that remote repository.
> 
> So the rest of the concerns were not addressed because they are not part of
> the goal. It's not the goal of the process to specify a strict format the
> repository needs to be exposed by over the network nor to ensure
> cryptographically signed files are transmitted. If those are needs for
> someone's use cases, then they should be implemented outside of the SWORD
> library and its native support. The goal of the library is to be very
> small, very fast, and as broadly portable as possible to more or less any
> device for which there is a C compiler available, and the goal of its
> support for remote repositories is to make it as simple as possible to get
> the data onto those devices. Thus, no standardized parser is required
> (though anyone using the library is free to extend its code to use one)
> because that becomes less portable and more heavyweight. Libcurl isn't even
> required - though without it access to HTTP/HTTPS sources vanishes because
> the library does not provide an implementation of that.

I agree that it has been made fairly simple for the regular user to 
distribute entire repositories, some caveats notwithstanding. Just copy 
your ~/.sword directory to another location type of stuff. However, when 
one wishes to go beyond such simple use cases things are often not 
simple any more.

I don't mean libsword should support all kinds of obscurities, but this 
seems to be where the goals of libsword authors often conflict with the 
goals of other developers wishing to use libsword, where "good enough" 
means different things for different parties etc.

> Again, small size, speed, and nimbleness are the goals of the library.
> Anything else that needs to be implemented for someone's requirements is up
> to them to implement above the library's level. Nothing stops someone from
> writing an application that connects over WebDAV to a server, fetches the
> SWORD files, checks them against cryptographic signatures, and uses well
> known libraries to handle all of that. But it's not the goal of libsword to
> offer that. That is much higher friction than the goal of the underlying
> library.
Libsword does not well lend itself to certain tasks, and some are 
impossible. For example, there is still no reliable way for users to 
abort module installation/download in a thread-safe manner. Working 
around such libsword shortcomings without changing libsword is not worth 
the effort.


Best regards,
Jaak


PS: Module handling would certainly have been simpler, more nimble and 
less code, if every module were a single file and repositories would 
have a single index file.
_______________________________________________
sword-devel mailing list: [email protected]
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page