<div dir="auto">It really comes down to if Troy likes the idea. On threads like this he usually lets everyone kick around ideas and discussions before making a final decision. In my impression he is most welcoming of extra code like this if it is optional. For instance the support for HTTP and HTTPS plus HTML parsing was more than initially desired, but once we proposed it could go behind the existing optional build flag for libcurl he was willing to accept it. That allows people who want the minimum experience on super tiny devices like a feature phone to still get their work done while people on bigger devices can compile in library support for the extra features.<div dir="auto"><br></div><div dir="auto">In my vision of the implementation you'd still send the data over an HTTP/S transport, so hiding the feature behind libcurl flags would make sense again. It also shouldn't need JSON or other more structured formats for parsing, because it would send the whole blob just as it should be returned from the method. But I would need to look deeply into the code and I'm on mobile right now. </div><div dir="auto"><br></div><div dir="auto">--Greg</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 3, 2024, 15:39 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 3:03 PM Greg Hellings <<a href="mailto:greg.hellings@gmail.com" target="_blank" rel="noreferrer">greg.hellings@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Sat, Aug 3, 2024, 14:41 Aaron Rainbolt <<a href="mailto:arraybolt3@gmail.com" target="_blank" rel="noreferrer">arraybolt3@gmail.com</a>> wrote:<br>
>><br>
>> 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>
><br>
><br>
> 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.)<br>
><br>
> 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.<br>
><br>
> I doubt that this would ever end up in the library, but if it did, that would probably be the most backwards compatible mechanism.<br>
<br>
That's pretty clever, and sounds like a reasonable way forward I<br>
suppose. If it's in conflict with the wishes of the libsword<br>
developers though, I'm not exactly sure it's worth doing. I could fork<br>
libsword or make my own library, but that would be a lot of work and<br>
probably wouldn't gain much traction anyway, so I'll probably just<br>
drop it. Hey, better to know early than to accidentally waste time :)<br>
<br>
> --Greg<br>
>><br>
>><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>
><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>