<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jan 19, 2014 at 5:19 PM, 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">Hi,<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...very immature or focused heavily on pure JS work that producing Sword<div class="im"><br>
bindings ranges from impossible (in the browser) to questionable<br>
(browser plugins) to an unexplored unknown (server-side plugins).<br>
</div></blockquote>
<br>
Last year I've started serveral efforts to access SWORD modules in Javascript. Since Javascript supports manipulating and handling binary data is no problem to access sword modules in Javascript if you know how to read them.<br>
</blockquote><div><br></div><div>It's that last phrase, "...if you know how to read them" that I wanted to obviate the need for.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
First I've tried to compile sword to JS with Emscripten, but without real success. After that I've started to work on a serverside nodejs implementation (pure JS and a wrapper around the native C++ lib). You can find the sources here:<br>
<br>
* <a href="https://github.com/zefanja/node-swordjs" target="_blank">https://github.com/zefanja/<u></u>node-swordjs</a><br>
* <a href="https://github.com/zefanja/sword-addon" target="_blank">https://github.com/zefanja/<u></u>sword-addon</a></blockquote><div><br></div><div>Drawing emphasis to my contention that server-side plugins are still a very immature option at this point.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Because every serverside solution has the problem to solve licence and sword module distribution issues I've ported my efforts to browser-side JS.<br>
<br>
The project is still a very early stage (and my free time is limited), but you are able to install and access sword modules in your browser. You can take a look at <a href="http://zefanjas.de/biblezng" target="_blank">http://zefanjas.de/biblezng</a> to see a working demo. Currently it supports Firefox only, because Chrome/IE don't support file blobs in indexedDB.<br>
<br>
You'll find the sources on Github, too.<br>
* the library: <a href="https://github.com/zefanja/swordjs" target="_blank">https://github.com/zefanja/<u></u>swordjs</a><br>
* the reference app: <a href="https://github.com/zefanja/biblez-ng" target="_blank">https://github.com/zefanja/<u></u>biblez-ng</a><br>
<br>
Perfomance is good in a the browser and acceptable on a low-end FirefoxOS device. But there is much room for optimizations (web workers, ...).<br></blockquote><div><br></div><div>This exactly exposes the problem: you now have 5 attempts to work on this spanning the course of a year. I'm sure in large part some of your difficulty stems from the fact that the format of the Sword module files is undocumented. There are multiple file formats you need to support, there's three levels of encryption possible on the content files, and there's two different encryption algorithms supported (I'd be curious how the performance of a book-level LZSS encrypted module shows up in FirefoxOS.</div>
<div><br></div><div>The difficulty with the approaches you've taken - except for your NodeJS plugin which doesn't help front-end JavaScript programmers like me - is that you've exposed yourself to a very high amount of effort if and when the format of a Sword module file changes. Currently we support zlib and LZSS compression of modules as they excel at speed (zlib) and maximal space savings (LZSS) with a preference for the zlib option because we don't feel that storage space is a major concern. But what if, in the future, Sword transitions to preferring some sort of middle ground and now you'll need to implement bzip2 compression? Or what if the structure of modules changes to depend on per-module defined versification schemes and leverages the "VerseTreeKey" that has been stubbed out and toyed with in the past? Or what if, in the far distant future, a new format of module is added that offers the possibility of storing data in a SQLite database? Now you need to go an implement your own code to interact with any of these possibilities. There are features in the C++ library that took a long time even to trickle down into JSword - like support for alternate versifications.</div>
<div><br></div><div>CrossWire only has two implementations of record for Sword: the C++ Sword engine and JSword. This is not to say we don't permit other people to access the modules or fight against people trying to import the data. There have been implementations that have read Sword modules into pre-rendered HTML files, into MySQL databases, and more. However, we have shied away from re-implementing the engine for those reasons above. Even when giving access in a language that supports binary file IO even better than JavaScript does (Objective-C, Python, Perl, C, and Java through the JNI bindings to name only a few) we have always encouraged people to tap into the existing module system. Even the Sword study tool (<a href="http://www.crosswire.org/study/">http://www.crosswire.org/study/</a>) runs pretty much right out of the C++ library bindings implemented through CORBA. This prevents each implementation from needing to re-implement and re-maintain the same code, over and over again. A number of other efforts have leveraged JSword in similar ways.</div>
<div><br></div><div>All I wished to do was demonstrate that the same could be accessed by JavaScript programmers with only a minor amount of server-side work.</div><div><br></div><div>--Greg</div></div></div></div>