[sword-devel] HTML5 File API and SWORD modules

[Greg Hellings]

On May 9, 2013 7:51 PM, "Stephan" <info at tetzels.de> wrote:
>
> Greg,
>
>
>> Any web server worth its salt and properly configured will already gzip
>> outgoing data. Thus the need to transfer the data in a compressed format
>> is unnecessary.
>
>
> 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 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.


>> Compressing for storage into a client-side storage mechanism would be
>> quite valuable on devices which truly are space-limited. But even a
>> low-end semi-intelligent phone these days comes with around 1G of
>> storage. Even our biggest Bible module, in its unprocessed full OSIS
>> glory only sits at a few MB. Such super space-limited devices are even
>> more bound by processor and RAM than by "disk" storage making any
>> on-the-fly processing quite painfully limiting.
>
>
> 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.

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.

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