[sword-devel] sword.js

[Greg Hellings]

On Mon, Jul 8, 2013 at 3:56 PM, Ryan Hiebert <ryan at ryanhiebert.com> wrote:

> Have you looked at untar.js?
>
>
> https://code.google.com/p/bitjs/source/browse/untar.js?r=0eca1f06d91e1477e3708531939c8071fc877855
>
> On a tangentially-related note, I've done some work on a python sword
> zmodule reader. It's stalled a bit now, because I've seen
> recommendations to use the C++ libraries, and just bindings to other
> languages. I understand the desire, but I think that Javascript is a
> good example of why that's not acceptable in all cases. For some
> distribution methods, it may be necessary to have everything
> implemented in a particular scripting language, such as for a
> Client-side Javascript bible reader.
>
> I think that encouraging using the C++ library is good, but it's even
> more important to make sure that the file formats are well documented,
> to allow alternate implementations if they are necessary.
>

Since we offer
1) Perl bindings
2) Python bindings
3) CORBA bindings
4) A Java port
5) ObjC bindings

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.

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?

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