<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 9, 2013 at 7:17 AM, Israel <span dir="ltr">&lt;<a href="mailto:israeldahl@gmail.com" target="_blank">israeldahl@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <div>On 05/09/2013 03:38 AM, Pola Edward
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hi every one,<br>
        this is very interesting topic :)<br>
        <br>
        Actually I like the idea of Greg, you can make a server side
        page that can convert current modules to a suitable format for
        JS Clients<br>
        <br>
      </div>
    </blockquote></div>
    +1 to that.  Cloud computing has become more popular (Joli Os,
    Peppermint OS, Chrome book OS, Firefox OS, etc..)<div class="im"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">But I wonder if the current sword modules format is
        suitable to the expansion of nowadays OSs ?<br>
        <br>
      </div>
    </blockquote></div>
    I might help to implement a way to access compressed files, like
    LiveCD&#39;s do with the squashfs, as a way to bundle things for quicker
    downloading and make things smaller for the lower end markets, and
    easier for people in restricted countries to have more tools in
    limited space, and of course countries where internet is hard to get
    to, or expensive :)</div></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>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 &quot;disk&quot; storage making any on-the-fly processing quite painfully limiting.</div>
<div style><br></div><div style>I would shy away from introducing such unnecessary complexity into a JavaScript-style solution. Now, if you can properly wrap and access the Sword library to access native-level C++ speeds then it&#39;s a different story altogether.</div>
<div style><br></div><div style>--Greg</div></div></div></div>