[sword-devel] HTML5 File API and SWORD modules

[Stephan]

>  > Jpp, that's true. What do you think: Should the server part be a
> service of crosswire (so it is hosted on their servers) or it is better
> do develop an easy-to-install server app, that everybody can install or
> host it by themself.
>  >
>  >
>
> I have no idea what "Jpp" means, despite the fact that you have used it
> a few times through this thread. So I'll just ignore it for now. :D

:) I use it often for "ok" or simple "yes".

> I think creating a reference application that can do the serializing is
> a great idea. However, hosting all of Crosswire's materials in a
> non-Crosswire environment through this mechanism runs into the same
> problem that mirroring the modules in any other fashion encounters with
> limited distribution requirements. Only CrossWire could host many of the
> modules due to their limited distribution rights, but creating an app
> that anyone could install and run (and doing so with Netty/Jetty in Java
> or similar would be relatively straightforward) could allow for some
> interesting abilities.
>
> E.g. a user could be presented a graphical list of their installed
> modules as discovered by the Sword/JSword engine and could manually
> check off the ones they want to share, etc. It could be extremely simple
> to deploy! But the main hosting of CrossWire's material would need to be
> done by CrossWire itself.

If we build an app everybody can hosted by themself, we need to cache 
the modules for serializing. I don't know if this is ok for Crosswire 
since this is a kind of mirroring. Otherwise we need the API at the 
crosswire servers.

>  > If we use indexedDB you can store their a compressed arrayBuffer/Blob
> (using zlib.js e.g.). Have you thought about how to make the keys for a
> key/value storage?
>  >
>
> There are a number of designs for it, including some that would support
> multiple versification schemes and even ones which could support a
> versification scheme unique to the module itself (although that more
> flexible implementation would require a little bit of tweaking tot he
> parse code).
>
> At one point BibleTime designed a way to implement a storage backend
> that was optimized for use in a database or key/value location. That
> design could be implemented with IndexedDB.

Do you have some documentation about this design? I still need to learn 
more about different versifications...

For parsing references we could use the bible refernce parser from 
openbibleinfo 
(https://github.com/openbibleinfo/Bible-Passage-Reference-Parser).

> I still think compressed storing is unnecessary, especially if we're
> going to support searching or similar. But it would be worthwhile to
> test its impact on storage space and retrieval performance with a
> variety of hardware.

--Stephan