On Wed, 29 Sep 1999, Tillman, James wrote:
> 1. I've worked out how to move the search code out of the CGI and into a
> "Searcher" class. This actually involved renaming the Parser class to
> "Searcher" and moving the code in there. A few public methods get renamed
> for clarity, several get added, and voila. Because I was working on code
I've been looking for more descriptive class names for a while. On the
htsearch side it's not bad, but the htdig Document/Retriever split was a
bit weird for me at first. This sounds fine to me.
> computations that Display currently performs to display its stars. I also
> believe that Display needs to concentrate on displaying the data returned by
> the ResultList and nothing else. Am I going to far here? If I'm correct, I
This is also something people have asked for. I think it makes sense to do
some re-factoring of code now. Besides, it seems like ResultList would be
the appropriate place for a number of eventual optimizations, but it's too
"dumb" now.
> share that branch if I may. I'm really nervous about making such heavy
> changes to this working code, although I feel confident I can pull it off.
Obviously, I'd be glad to make branches for various projects. Instead, how
about I call for a feature freeze for 3.2 in two weeks, then we'll make a
3.2 branch and this (and other questionable code) can go on the mainline.
I'd like to get a 3.2b1 release out soon. If we can draw up a quick list
of any features from 3.1.x that are currently broken in 3.2, it will make
it easier to ensure we're ready--about the only *new* feature that's
currently missing is my ExternalTransport class. I'm probably forgetting
something or other.
-Geoff
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
