On Sat, Aug 3, 2024 at 3:03 PM Greg Hellings <greg.helli...@gmail.com> wrote: > > > > On Sat, Aug 3, 2024, 14:41 Aaron Rainbolt <arraybo...@gmail.com> wrote: >> >> On Sat, Aug 3, 2024 at 5:30 AM Jaak Ristioja <j...@ristioja.ee> wrote: >> > >> > On 29.07.24 11:10, Aaron Rainbolt wrote: >> > > The idea is to make it so that *existing* SWORD clients can be able to >> > > access data on remote servers without downloading the whole thing. I >> > > laid out some reasons why this is helpful in certain use cases in my >> > > first email. Existing SWORD clients are meant to retrieve information >> > > from libsword and then render it in somme way, thus to maximize the >> > > possibility of adoption, my hope was to implement in libsword the >> > > ability to fetch "raw" data from a remote server and then pass it >> > > through to the client, which already has code for rendering it however >> > > the client chooses. Ideally a client should need to do nothing more >> > > than point an SWMgr object at the remote server and then use it exactly >> > > the same way it would use a local repository (perhaps with some extra >> > > error checks for things like timeouts, interrupted connections, and >> > > whatnot). >> > >> > In my opinion, this is not worth the effort. Is it really too much for >> > the client to download the whole module(s) to some temporary storage or >> > RAM? >> >> Depending on the module, yes. I've worked on Internet connections that >> were so slow that module downloads repeatedly timed out and failed. If >> I am using a SWORD client that has access to remote data, I don't want >> to have to wait thirty seconds to switch modules, and have some >> modules just outright refuse to work. I want to be able to work almost >> as fast and seamlessly as if I had the modules locally. Also for >> someone who used a lot of modules in their study, having these modules >> be temporarily downloaded on the fly could consume a lot of RAM or >> disk space (which may be a problem for users who are stuck with >> underpowered hardware), and they would have to be repeatedly >> downloaded every time they opened the client. For someone working with >> a modern laptop on gigabit WiFi, this might be comfortable, but for >> the person in (for instance) Africa working with a 32-bit Celeron on a >> dialup connection, this is not going to work. >> >> > Also, how do you envision this to work with existing SWORD clients? >> >> Ideally when making an SWMgr object, they could just pass a URL to the >> object pointing it to the remote repository, then use it as if it were >> local. Listing all modules would give you a list of all remote >> modules, fetching parts of a module would fetch them from a remote >> server, etc. For the client, it should be totally transparent except >> for the initial connection, and error handling in the event of a >> network issue. > > > To fit better within the Sword library implementation, you probably would > just have the remote server setup as a normal remote like the current ones. > When a user installed a module from the server, it would be sent the conf > file which would hold all the metadata I mentioned earlier. However, instead > of one of the existing SWModule implementation classes that reads from disk > (we have zText classes for compressed files, RawText for uncompressed, etc) > the implementation would be a RemoteText and it would simply request from the > original server the binary blobs it needs. (In Sword parlance, "Text" are > modules with verse based keys like a Bible or Commentary. But the same > parallel exists for LD - lexicon/dictionary - and general books. You would > need to implement both of those if you wanted to support the full set of > modules.) > > If you could accomplish that, it should be completely transparent to the > existing clients and not require much tweaking to the library. The SWMgr > mechanism that instantiates the concrete class based on the module config > type would need to know about your classes and that should be it. > > I doubt that this would ever end up in the library, but if it did, that would > probably be the most backwards compatible mechanism.
That's pretty clever, and sounds like a reasonable way forward I suppose. If it's in conflict with the wishes of the libsword developers though, I'm not exactly sure it's worth doing. I could fork libsword or make my own library, but that would be a lot of work and probably wouldn't gain much traction anyway, so I'll probably just drop it. Hey, better to know early than to accidentally waste time :) > --Greg >> >> >> > Best regards, >> > Jaak >> > _______________________________________________ >> > sword-devel mailing list: sword-devel@crosswire.org >> > http://crosswire.org/mailman/listinfo/sword-devel >> > Instructions to unsubscribe/change your settings at above page >> _______________________________________________ >> sword-devel mailing list: sword-devel@crosswire.org >> http://crosswire.org/mailman/listinfo/sword-devel >> Instructions to unsubscribe/change your settings at above page > > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > http://crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
