[sword-devel] JavaScript & SWORD modules

[Greg Hellings]

On Sun, Jan 19, 2014 at 11:13 PM, Stephan <info at tetzels.de> wrote:

> Hi Greg,
>
>
>  My purpose was to strip away that layer and just show that there is not
>> a need, from the desires I have seen on this list so far, for a pure
>> JavaScript implementation. Not that it can't be done or that people will
>> fight you on it if you really want to put in that level of effort. I
>> only wanted to demonstrate that the results can also be acquired through
>> JSON which is so native to JavaScript and then we JavaScript developers
>> can do what we do best: focus on the front-end presentation of the UI
>> and the rendering of the material. Why tackle more of the stack than is
>> necessary? If you can stand on the shoulders of 20 years of development
>> effort that's gone into Sword (and I don't know how much, but plenty
>> that's gone into JSword) to build your utility, why wouldn't you? That's
>> what Xiphos, BibleTime, BPBible, BibleCS, xulsword, PocketSword, Bishop,
>> AndBible, the web study tool, numerous helper scripts written in Perl
>> and Python, Bible Desktop, Eloquent/MacSword, and still yet others have
>> all opted for. All of them, and more, rely on only two implementations
>> of the Sword engine because the shared effort provides these people the
>> ability to value-add, rather than toil away fixing all the bugs and
>> reverse engineering the file structure.
>>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>

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 http://thehellings.com:10001/demo. 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.

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.

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.

The source file is
https://github.com/greg-hellings/jsword-json/blob/master/src/main/jamon/templates/Demo.jamon
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!

--Greg


>
> Blessings,
> Stephan
>
> PS: BTW, if you're looking for a good cross-platform app framework, take a
> look at enyojs.com ;)
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140125/4eea3974/attachment.html>