[sword-devel] Sword questions

Paul Gear sword-devel@crosswire.org
Wed, 24 May 2000 19:25:37 +0000

Jeffrey Hoyt wrote:
> (Please forgive me if I've already posted these questions, my e-mail was
> giving me some problems so I couldn't tell what was posted and what was
> not...thanks!)

I got the previous one twice.

> Here are four ideas that I believe could improve SWORD (though not being
> a programmer these may be wildly unrealistic... ;-):
> 1.  Sword should be able to read from zipped modules.  This is what
> (more or less) the new KWord and XMMS do.  The .conf file would stay in
> the *.zip file and be read from there.

I think that it would be nice to have this, too.  Unfortunately, gzip
and pkzip are stream compressors, not block compressors, as Joachim has
pointed out, so the entire file would have to be decompressed rather
than just the appropriate parts.  Also, unlocking commercial texts
requires saving a key to the .conf file, so i expect these would need to
be outside the .ZIP file.

However, compression would really be a good idea.  (My hard drive is
getting very full!)  STEP uses a block compression algorithm that allows
fast, partial decompression.  It would be great if Sword could, too.

> 2.  Modules should be placed in .../sword/modules, and not have to worry
> about /texts, /commentaries, /raw, /gbf, and other such like that could
> be very confusing to somebody new (even to me!).  Module type, etc.
> would be read from the .conf file.

Why do you want to make this change?  It is very rare that most users
should need to go looking in there, but those structures provide
understandability and ease of management for developers.

> 3.  There should only be ONE format for SWORD modules.  Whether it's
> RTF, THML, or whatever, that would make it much easier to work with.
> Also, this format should allow hyperlinking between modules.

There is absolutely no reason that this is necessary, and a lot of good
reasons why it is not.  How would it make working with Sword easier? 
The user doesn't see the format of the files from the frontend anyway. 
Wide data format support is one of the most important things Sword

The problem with a single format is that the texts themselves come in
all sorts of different formats.  It is best to preserve them and write
drivers for the different formats rather than convert them and risk
losing information.

> 4.  Commentaries should follow the same display format as texts, with
> one chapter's worth per page, rather than one verse per page.  This
> would make it much easier to use.

I like that idea.

"He must become greater; i must become less." - John 3:30