[sword-devel] HTML5 File API and SWORD modules
info at tetzels.de
Thu May 9 19:44:10 MST 2013
> > 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
> > 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
> 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.
More information about the sword-devel