I don't see that we need to document the file structure any further. If you want a client-side application to be able to read a module, then you are more than able to setup and configure a server that can translate between an installed module and any web-friendly format you desire. If you can't find a simple web framework that operates in one of those 5 languages (and one of them is already a web-services oriented binding) then feel free to read the C++ or Java file reading architecture.
Yes, that is one way to do it, but you have to get the permission to distribute the modules that are not public domain or creative commons.
If you work it right, you can even have the library readily configurable with multiple Sword remote repositories that can query for modules on the fly, etc. Why the need to contort a client-side UI language like JavaScript to read binary file formats?
I think Javascript is today much more than just a UI language. My main reasons to start this project are:
* full offline app - you should be able to install a module from a zip file you get from a friend etc. (I'm currently living in a developing country and internet access is more or less stable - I you have any.) * Portability - I don't want to make plugins for every plattform or compile binaries * target new platforms like Firefox OS that currently don't have support for binary plugins
* I want to see what is possible with todays web technologies Blessings, Stephan _______________________________________________ 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
