<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 29, 2024 at 3:26 AM Aaron Rainbolt <<a href="mailto:arraybolt3@gmail.com">arraybolt3@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 28 Jul 2024 23:08:33 -0500<br>
Greg Hellings <<a href="mailto:greg.hellings@gmail.com" target="_blank">greg.hellings@gmail.com</a>> wrote:<br>
> <br>
> Now, to switch to the idea of a specialized SWORD protocol to address<br>
> the user who does not want to fetch the entirety of a module: why?<br>
> The library can already generate HTML documents and document<br>
> fragments. Just do the rendering on the server and pass the fragment<br>
> to the client over HTTP. Wrap the rendered string into a JSON object<br>
> if you need to. Why try to pass the binary blob of some random data<br>
> to the remote unit when you could already render it on the server?<br>
<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></blockquote><div><br></div><div>A few caveats that might dissuade you from sending the raw data:</div><div><br></div><div>The raw data can be in multiple formats, depending on the source module and fields in use. OSIS, TEI, ThML, RTF, and GBF are the most common formats. Meanwhile there are also a few major output formats that might be requested. HTML, RTF, plain text are the most common. But I think there might also be support for TeX? I'm not 100% sure. All of that metadata is stored in the module configuration file and not at the verse level in the resulting file. Why force the client to handle this parsing and consume the extra information when it could just slurp up the requested format as rendered by the server. On top of that the configuration file will have information on if there are lemmas, footnotes, and other information all of which will inform how to render a particular blob of text.</div><div><br></div><div>Much simpler to just tell the server, "Please send me HTML and strip out footnotes" than to try and encode all of that, send it to the client, and then render it there. Every round trip would essentially need the fully parsed config file to travel with it in your proposed raw form.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> A simple REST library written in something like Go could easily be<br>
> linked to the libsword C library. It could query libsword to get the<br>
> list of modules and expose them, along with certain query parameters<br>
> specifying the format request. Then serve the resulting text over<br>
> HTTP. So a client library could hit something like<br>
> <a href="http://mylibrary.com/texts/KJV/Gen/1/1?format=html" rel="noreferrer" target="_blank">http://mylibrary.com/texts/KJV/Gen/1/1?format=html</a> and it will get back<br>
> {"osisRef": "Gen.1.1", "text": "<p>In the beginning...</p>"}. You<br>
> wouldn't need to write some low level application protocol. You would<br>
> save the client device from needing to render the text and have extra<br>
> knowledge of the module. You wouldn't have to alter the library in<br>
> any fashion.<br>
<br>
This is similar to what I was thinking. I wasn't sure if JSON was the<br>
best wrapper to do it in, but I don't see any reason to use<br>
anything else, other than SWORD's apparent preference for XML-like<br>
formats. However my "text" field would probably look more like "text":<br>
"$$$Revelation of John 22:19\n<w lemma="strong:G2532 lemma.TR:και"<br>
morph="robinson:CONJ" src="1">And</w>..." or some such (this is what<br>
mod2imp spit out when I used it to get an example).<br></blockquote><div><br></div><div>There are two difficulties with this as I can see. The first I mentioned in the paragraph above. You and I can look at this and recognize it as OSIS, but that information is only encoded in the configuration file. Likewise, telling the renderer that lemmas and morphology are supported is encoded there. Why not just allow the library to handle that?</div><div><br></div><div>Secondly, the library has no knowledge of the import format. Knolwedge of parsing that block from an input formatted file is known only in the imp2mod utility. That utility is not linked into the library. It is frequently distributed with the library, but it is not an inherent part of it. Similarly the mod2imp utility is not a portion of the library. Those two applications handle the generating and parsing of the input format, and no attempt is made by either one to preserve the full round-trip functionality of the underlying encoding format. You would need to re-implement parsing of that format into your library and you would lose the extra data that is not held internal to the passage requested.</div><div><br></div><div>I don't see any benefit to transmitting the module in this way when you could just ask the server for the rendered text. Especially if you are looking at this from the type of limited device where such a feature would be helpful, you might as well offload as much of the processing work as possible to the server. Just ask it for the format you want to render, and consume what it sends you.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> A simple application like this could be written up, distributed in a<br>
> static binary, and anyone would be able to hit it for a REST<br>
> accessed, rendered format of a given text. Going back to the goal of<br>
> simplicity: this application could be run by anyone on any computer<br>
> where a SWORD library already existed, and it could serve the<br>
> baseline of those peoples' needs.<br>
> <br>
> That's just an idea I've had bouncing around in my head for a long<br>
> time. I just have no need to access the scripture over REST or I<br>
> would have already written it. All the bits are already out there.<br>
> There are lots of good REST frameworks, every language with them has<br>
> the ability to encode JSON, and most of the popular ones we have<br>
> bindings for the language in (Python, PHP, Java) or it can easily be<br>
> integrated directly (CGO).<br>
<br>
This is a really good idea, and if this is going beyond what libsword<br>
is designed for, that's probably the route I'll take. I have a<br>
preference for C# for development tasks along these lines so I'll<br>
probably try to resurrect that first (the actual VS solution in<br>
libsword is *old* but the SWIG code should be up-to-date, so I don't<br>
imagine it will be *too* hard to get it going again - failing that,<br>
C++/Qt is probably my next choice though Qt is a bit of a strange<br>
choice for a server application). Then I'll probably implement something<br>
more-or-less like what you're mentioning here. Might not catch on, but<br>
if nothing else it will be interesting.<br></blockquote><div><br></div><div>I don't know about C# bindings for libsword. And I'm not completely sure the VS build files ever worked. Maybe they did, but if so it was a long time ago. When I have compiled for Windows I used the MinGW tools from Linux to just cross-compile the library and tools. I also have written a grand total of about 20 lines of C# in my life, so I can't really give you any specifics on leveraging it. I know it at least used to be very well regarded in web services, but it has been a long time since I have seen greenfield web work written in it. But I have not kept my finger on the pulse of that.<br></div><div><br></div><div>I don't know that Qt is going to give you very good Web Server support. It's a great utility library but that's not really its goal. Their documentation page on their web server includes this warning: "Qt HTTP Server does not have many of the more advanced features and 
optimizations that general-purpose HTTP servers have. It also has not 
seen the same scrutiny regarding various attack vectors over the 
network. Use Qt HTTP Server, therefore, only for local connections or in
 a trusted network, and do not expose the ports to the internet."</div><div><br></div><div>I've been in professional web dev at various parts of my career. For new work I would only tackle either Python, NodeJS, or Golang right now. Python we have Swig support for, NodeJS we don't really have support for in the library but there is an existing application called Ezra which is written in NodeJS and probably has enough support for the needs here. And of course Golang (and Rust) can easily tap into an existing C library with no real effort required.</div><div><br></div><div>So yeah - my suggestion would be to push the rendering off into the server code rather than trying to get the raw format over to the client app. And to leverage the easiest bindings. Either Swig or one of the languages that is easy to link against the raw library.</div><div><br></div><div>--Greg<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Hope you're doing well,<br>
Aaron<br>
<br>
> --Greg<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="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>