[sword-devel] sword.js

[DM Smith]

There is no documentation of file formats. The code for it has very little documentation either. The intention is that SWORD C++ is used directly or via bindings.

In Him,
	DM Smith

On Jul 9, 2013, at 5:16 PM, Ryan Hiebert <ryan at ryanhiebert.com> wrote:

> Thanks for responding Greg. I've had a little trouble finding
> documentation on the file formats, though I have found some, mostly
> related to the modules.d files. Is there more documentation that you
> can point me to? What would you consider the primary documentation for
> the file formats currently?
> 
> On Mon, Jul 8, 2013 at 2:06 PM, Greg Hellings <greg.hellings at gmail.com> wrote:
>> 
>> 
>> 
>> 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
>> 
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20130709/e99da383/attachment.p7s>