<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 8, 2013 at 9:45 AM, Stephan <span dir="ltr"><<a href="mailto:info@tetzels.de" target="_blank">info@tetzels.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greg,<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A client-side Sword application could do something similar. I had begun<br>
work on such an app at one point. However, in order to fetch data, a<br>
native client-side JavaScript implementation would be much better off<br>
leveraging the existing technologies - like localStorage and IndexedDB -<br>
for local storage and retrieval and downloading the requested materials<br>
from a remote server that offered them up in an appropriate format. The<br>
Sword format is poorly designed for client-side JavaScript access. But<br>
the Sword library, either through bindings into Python or Perl or<br>
through directly writing a C-based application or using Java bindings or<br>
JSword could easily be made to serve up data in an XML format (imagine<br>
that!) or JSON (personally, I believe this is better for web-based<br>
transport) which can then be cached on the local side.<br>
</blockquote>
<br></div>
My aim is to build an JS app, that is fully a offline app.(maybe you need a internet connection to download the sword modules and store them in some kind of storae (indexedDB, ...), but you can also do local import). There is no need to convert the modules to JSON or XML, since we can access the sword format in JS.</blockquote>
<div><br></div><div style>If we already have a connection to the server when downloading, why not allow the server to run the Sword library directly - e.g. through JSword or the JNI, Python or Perl bindings of Sword and do the OSIS/GBF/ThML --> HTML rendering? Then it can pipe that into a JSON or XML for delivery to the client-side. It can also normalize the encoding to UTF-8. The client can keep the resulting module data in a standard storage mechanism on its end for full offline access. That's the structure I was going for.</div>
<div style><br>Then, the client-side needs only to implement some of the basic Sword functionality, like parsing references and understanding different versification schemes.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At that point, though, you're talking about something which is largely a<br>
port of Sword into JavaScript rather than just a client. It would need<br>
to be capable of understanding and parsing input and transforming that<br>
into the appropriate values for a key-value store in order to retrieve<br>
the rendered data.<br>
</blockquote>
<br></div>
Jpp, it is more like a port to JavaScript. But I don't want to write everything from scratch and hope the Emscripten project will do good progress =)</blockquote><div><br></div><div style>I think separating your application into a server doing Sword export and a client caching the rendered data into its local mechanisms will prevent you a world of headache.</div>
<div style><br></div><div style>--Greg</div></div></div></div>