<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jan 19, 2014 at 11:13 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Greg,<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
My purpose was to strip away that layer and just show that there is not<br>
a need, from the desires I have seen on this list so far, for a pure<br>
JavaScript implementation. Not that it can't be done or that people will<br>
fight you on it if you really want to put in that level of effort. I<br>
only wanted to demonstrate that the results can also be acquired through<br>
JSON which is so native to JavaScript and then we JavaScript developers<br>
can do what we do best: focus on the front-end presentation of the UI<br>
and the rendering of the material. Why tackle more of the stack than is<br>
necessary? If you can stand on the shoulders of 20 years of development<br>
effort that's gone into Sword (and I don't know how much, but plenty<br>
that's gone into JSword) to build your utility, why wouldn't you? That's<br>
what Xiphos, BibleTime, BPBible, BibleCS, xulsword, PocketSword, Bishop,<br>
AndBible, the web study tool, numerous helper scripts written in Perl<br>
and Python, Bible Desktop, Eloquent/MacSword, and still yet others have<br>
all opted for. All of them, and more, rely on only two implementations<br>
of the Sword engine because the shared effort provides these people the<br>
ability to value-add, rather than toil away fixing all the bugs and<br>
reverse engineering the file structure.<br>
</blockquote>
<br></div>
I don't want to be offensiv, just want to share my efforts. I really would prefer a way not to write everything from scratch and you're right, there are limitations in a pure JS implementation. That's the reason why I observe several other ideas like the nodejs things. On the other side I'm still excited what is possible in pure client-side JS.<br>
<br>
One of the main reasons, why I've started swordjs was FirefoxOS. They don't allow native plugins. The sword project is a very great and I respect all the efforts that went into this library. Someone in this list suggested to make phonegap plugins and I think that is a very good idea, because you can use the native lib offline and have a JS-frontend on the other side. But I don't have an android/iOS device and so my motivation isn't that high to start this, although it would be a great project.<br>
<br>
BibleZ HD (a webOS app) has a native plugin and it was great to rely on such a good library like libsword. From today's perspective using the native lib directly or through bindings/plugins would be the best way.<br>
<br>
As I've said, FxOS was one of the main reason. Because I use it as my second phone, I want to have offline access a bible, so there is a big personal motivation, too ;) Cause I like to develop things in Javascript, swordjs is a good thing (for me) to see, what you can do in pure clinet-side Javascript.<br>
</blockquote><div><br></div><div>If you can get the raw Sword plugins running natively on your system, that's obviously the way to go. I wanted to demonstrate, though, that it is possible to use this data offline and automate the process of acquiring it. To that end, I wrote a simple demo set of jQuery interactions. You can now access them from <a href="http://thehellings.com:10001/demo">http://thehellings.com:10001/demo</a>. There you can programmatically list out all the installed modules on the server, fetch a list of their top-level entries, and import them locally. Once they are imported you can access them with another very simplistic UI. That UI only really works for Bibles, since that's the most interesting data type, but in a real application the UI would be responsive to the type of module being used.</div>
<div><br></div><div>With only a few lines of code this could be turned into an actual offline webapp and run in a browser with no web connection. After the initial import of the data, all fetching and displaying of retrieved data is done out of the localStorage and indexedDB interfaces functionality. This frees up the browser or other device to freely disconnect from the network and keep the data stored locally for processing or display.</div>
<div><br></div><div>Obviously I cut lots of corners to make the demo file simple to understand for the programmer, at the expense of functionality and performance in lots of places (you can notice this quite readily if you try to do any operations against the Webster's Dictionary module). Again, I only want to demonstrate that tying an app to the binary representation of a Sword module is unnecessary, and the app can still be offline and in JavaScript provided the module is provided in a JSON format for import.</div>
<div><br></div><div>The source file is <a href="https://github.com/greg-hellings/jsword-json/blob/master/src/main/jamon/templates/Demo.jamon">https://github.com/greg-hellings/jsword-json/blob/master/src/main/jamon/templates/Demo.jamon</a> here if anyone cares at this point to see how the data is fetched, stored, etc. I regret that my demo server has WebSocket transport disabled, but the WebSocket library I'm using relies on a Java class that was introduced in Java SE 7 whereas my server only has Java 6 installed. I've had fine success with it running against Java 7, and if someone runs it locally they should be able to leverage either transport mechanism to demo to themself. This is especially sad because WebSockets are a lovely, novel HTML5 technology that is even supported by IE 10 and 11!</div>
<div><br></div><div>--Greg</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Blessings,<br>
Stephan<br>
<br>
PS: BTW, if you're looking for a good cross-platform app framework, take a look at <a href="http://enyojs.com" target="_blank">enyojs.com</a> ;)<div class=""><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/<u></u>mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</div></div></blockquote></div><br></div></div>