<div dir="ltr"><p dir="ltr"><br>
On May 9, 2013 7:51 PM, "Stephan" <<a href="mailto:info@tetzels.de" target="_blank">info@tetzels.de</a>> wrote:<br>
><br>
> Greg,<br>
><br>
><br>
>> Any web server worth its salt and properly configured will already gzip<br>
>> outgoing data. Thus the need to transfer the data in a compressed format<br>
>> is unnecessary.<br>
><br>
><br>
> 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.<br>
><br>
></p><p style>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</p><p style><br></p><p style>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.</p>
<p style>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.<br>
</p><p dir="ltr"><br>
>> Compressing for storage into a client-side storage mechanism would be<br>
>> quite valuable on devices which truly are space-limited. But even a<br>
>> low-end semi-intelligent phone these days comes with around 1G of<br>
>> storage. Even our biggest Bible module, in its unprocessed full OSIS<br>
>> glory only sits at a few MB. Such super space-limited devices are even<br>
>> more bound by processor and RAM than by "disk" storage making any<br>
>> on-the-fly processing quite painfully limiting.<br>
><br>
><br>
> 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?<br>
></p><p style>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).</p>
<p style>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.</p><p style>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.</p>
<p style>--Greg</p>
</div>