[sword-devel] Some other fast search index options

[Paul Gear]

"Troy A. Griffitts" wrote:
> 
> > ...sometimes.  I've certainly found some STEP books that it wouldn't
> > decompress correctly, but that could be just because of me making a
> > mistake with the rather obtuse API.
> ...
> The compression routine works for lzss compressed data.  It knows
> nothing about STEP.  If the STEP module used the prescribed lzss
> compression, then it should work :)

It is indeed possible that STEP books might not stick to their spec.  I
guess i was assuming that lzss == lzss == lzss.  Sorry.

> Obtuse!?!??  :)  I thought the API was clever 3 years ago! :)  It's
> really not that bad in my opinion.

My attitude to APIs is that if you sit back and think "that's really
clever" when you look at one you've written, then you've done it wrong. 
If you look back and think "a 12-year-old could understand that", then
you've done it right.

My preaching lecturer at Bible college introduced us to the 3 principles
of good communication:
	1.  Be clear
	2.  Be clear
	3.  Be clear
I stole this for my programming philosophy.  If it is not perfectly
clear to me what the code does after reading it once, then it is not
clear enough.

That's my $0.02.  Feel free to disagree.  flames >/dev/null 2>&1  :-)

>  It gives you some options that might
> not be intuitive, like subclassing and overriding only a few methods to
> make it work against other datasources besides string buffers, but you
> don't HAVE to use these if you don't want to.  The simplest use is:
> ...
> Now that's not TOO OBTUSE is it?!

Having the code for the compressors and uncompressors mixed in together
is unclear in my opinion.  Why would i ever want to compress and
uncompress at the same time?  I either want to read a module's text
(uncompress), or package a text into module (compress) - never both.  If
the options are not intuitive, then the API is obtuse.

Perhaps i was also colouring my opinion of the API too much by reading
the code.  Your basic example was easy to understand.  Reading the code
and adding bzip2 support would not be that easy.

> ...
> You can make a BZipCompress::SWCompress for us if you really want to.

When i finish my Greek course this semester it might be a possibility. 
But don't be offended if i don't start with your code.  :-)

Paul
---------
"He must become greater; i must become less." - John 3:30
http://www.bigfoot.com/~paulgear