On Thu, May 9, 2013 at 7:17 AM, Israel <israeld...@gmail.com> wrote: > On 05/09/2013 03:38 AM, Pola Edward wrote: > > Hi every one, > this is very interesting topic :) > > 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 > > +1 to that. Cloud computing has become more popular (Joli Os, > Peppermint OS, Chrome book OS, Firefox OS, etc..) > > > But I wonder if the current sword modules format is suitable to the > expansion of nowadays OSs ? > > I might help to implement a way to access compressed files, like > LiveCD'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 :) >
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. 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. 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's a different story altogether. --Greg
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
