I've been following the discussions on the dev mailing list here very closely,
and can see a desire to improve htsearch is shared by several developers. I
wanted to take a moment to outline some of my thoughts on the subject, and to
detail some experiments I've tried in the recent past:
* What I really want to see most of all in htsearch is an API. Right now
htsearch itself is the only program that can do a search using the htsearch
code. It doesn't have to be this way. With some work, the htsearch search
code could be placed in a C++ class that would be usable by any program. It
could even be compiled into a loadable module, making its reuse even easier.
* Achieving an API for htsearch will require moving a lot of code out of the
htsearch.cc and parser.cc modules and into a new class. I've been calling it
Searcher.cc, but in deference to Andrew S., who believes classes should model
form, rather than function, it could also be called Search.cc and represent an
instance of a search on the htdig system. I tend to treat my objects as little
animals which do things and have traits, but I think in this case, the
distinction isn't very important.
*My original attempt to achieve such an API was actually successful to a
degree, and I actually committed the changes to the default htdig3 CVS branch
(which was open to experimentation at the time). What I ended up with was a
very stripped down htsearch.cc that simply used Searcher.cc to do the
searching. Searcher.cc returned a ResultList, which was then provided to
Display.cc for rendering. Display.cc was dumbed down so it was unable to
access the database directly, and ResultList was smartened up to be able to
retrieve the data that Display needed. I felt I had achieved a pretty good
encapsulation of functionality.
*While my original Searcher.cc wouldn't even work in the current state of the
source (due to the multiple database support that was added recently), I
think we might be able to take these concepts and still achieve a usable API.
I've seen discussing of a SyntaxTree class, which sounds good to me, and that
would presumably be used by the Searcher class if the scheme mentioned above
were used. My original Searcher ended up being quite large (containing all of
parser.cc and most of htsearch.cc when it was all finished).
*In case anyone's interested, here's a summary of the Seacher object I ended up
with in my original experiment:
Attributes (available through get/set methods):
->Error: from parser.cc
->WordDB: from htsearch.cc's main
->SearchWords: from htsearch.cc's main
->RequiredWords: from htsearch.cc's main
->Exclusion: from htsearch.cc's main
->Restriction: from htsearch.cc's main
->ConfigVal: allow setting a configuration value
->ConfigFile: allows setting the configuration file
->Debug: sets the debug level (from parser.cc and htsearch.cc)
->Database: from parser.cc and htsearch.cc
Methods:
->execute: performs the search and returns a ResultList, which is capable of
retrieving the data from the database (taking the load off of the Display
object).
*I realize all this talk may not be of any use to the discussion, but I thought
I'd just toss it out there in case it would be. I hope to be of some help in
making htsearch usable from other programs via source or loadable module, mainly
because I'm very interested in getting a Perl module linked to it so you can
query htdig through the htsearch code.
Please let me know what your thoughts are on the above.
Jamie T.
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
