<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 3, 2024, 14:41 Aaron Rainbolt <<a href="mailto:arraybolt3@gmail.com">arraybolt3@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Aug 3, 2024 at 5:30 AM Jaak Ristioja <<a href="mailto:jaak@ristioja.ee" target="_blank" rel="noreferrer">jaak@ristioja.ee</a>> wrote:<br>
><br>
> On 29.07.24 11:10, Aaron Rainbolt wrote:<br>
> > The idea is to make it so that *existing* SWORD clients can be able to<br>
> > access data on remote servers without downloading the whole thing. I<br>
> > laid out some reasons why this is helpful in certain use cases in my<br>
> > first email. Existing SWORD clients are meant to retrieve information<br>
> > from libsword and then render it in somme way, thus to maximize the<br>
> > possibility of adoption, my hope was to implement in libsword the<br>
> > ability to fetch "raw" data from a remote server and then pass it<br>
> > through to the client, which already has code for rendering it however<br>
> > the client chooses. Ideally a client should need to do nothing more<br>
> > than point an SWMgr object at the remote server and then use it exactly<br>
> > the same way it would use a local repository (perhaps with some extra<br>
> > error checks for things like timeouts, interrupted connections, and<br>
> > whatnot).<br>
><br>
> In my opinion, this is not worth the effort. Is it really too much for<br>
> the client to download the whole module(s) to some temporary storage or RAM?<br>
<br>
Depending on the module, yes. I've worked on Internet connections that<br>
were so slow that module downloads repeatedly timed out and failed. If<br>
I am using a SWORD client that has access to remote data, I don't want<br>
to have to wait thirty seconds to switch modules, and have some<br>
modules just outright refuse to work. I want to be able to work almost<br>
as fast and seamlessly as if I had the modules locally. Also for<br>
someone who used a lot of modules in their study, having these modules<br>
be temporarily downloaded on the fly could consume a lot of RAM or<br>
disk space (which may be a problem for users who are stuck with<br>
underpowered hardware), and they would have to be repeatedly<br>
downloaded every time they opened the client. For someone working with<br>
a modern laptop on gigabit WiFi, this might be comfortable, but for<br>
the person in (for instance) Africa working with a 32-bit Celeron on a<br>
dialup connection, this is not going to work.<br>
<br>
> Also, how do you envision this to work with existing SWORD clients?<br>
<br>
Ideally when making an SWMgr object, they could just pass a URL to the<br>
object pointing it to the remote repository, then use it as if it were<br>
local. Listing all modules would give you a list of all remote<br>
modules, fetching parts of a module would fetch them from a remote<br>
server, etc. For the client, it should be totally transparent except<br>
for the initial connection, and error handling in the event of a<br>
network issue.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.)</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I doubt that this would ever end up in the library, but if it did, that would probably be the most backwards compatible mechanism. </div><div dir="auto"><br></div><div dir="auto">--Greg</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Best regards,<br>
> Jaak<br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank" rel="noreferrer">sword-devel@crosswire.org</a><br>
> <a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer noreferrer" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank" rel="noreferrer">sword-devel@crosswire.org</a><br>
<a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer noreferrer" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote></div></div></div>