[sword-devel] HTML5 File API and SWORD modules

[Greg Hellings]

On Wed, May 8, 2013 at 9:45 AM, Stephan <info at tetzels.de> wrote:

> Greg,
>
>
>  A client-side Sword application could do something similar. I had begun
>> work on such an app at one point. However, in order to fetch data, a
>> native client-side JavaScript implementation would be much better off
>> leveraging the existing technologies - like localStorage and IndexedDB -
>> for local storage and retrieval and downloading the requested materials
>> from a remote server that offered them up in an appropriate format. The
>> Sword format is poorly designed for client-side JavaScript access. But
>> the Sword library, either through bindings into Python or Perl or
>> through directly writing a C-based application or using Java bindings or
>> JSword could easily be made to serve up data in an XML format (imagine
>> that!) or JSON (personally, I believe this is better for web-based
>> transport) which can then be cached on the local side.
>>
>
> 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.


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.

Then, the client-side needs only to implement some of the basic Sword
functionality, like parsing references and understanding different
versification schemes.


>
>  At that point, though, you're talking about something which is largely a
>> port of Sword into JavaScript rather than just a client. It would need
>> to be capable of understanding and parsing input and transforming that
>> into the appropriate values for a key-value store in order to retrieve
>> the rendered data.
>>
>
> 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 =)


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.

--Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20130508/94a741f9/attachment.html>