Re: Searching issue

[Robert Myers <ccrider@whiterose.net>]

On Wed, 28 Apr 1999, Aaron D. Turner wrote:
> The processor/reformatter will be mod_perl.  This will save us an extra
> fork().  There's no way to aviod a fork() with htsearch.
> 
> Basically the PHP search form will call /perl/search.pl which is a
> mod_perl script.  search.pl will execute the htsearch cgi (a C program),
> read in the output of htsearch (stdout), reformat it with the proper
> header/footer info (to make it look like our site), and return the results
> to the browser.

	OK, sounds good to me.

> That's still true, and this doesn't effect this.  Basically the reason for
> the mod_perl wrapper is this (example):
> 
> Joe drills down to Networking->Dialup->PPP
> Joe does a search on "CHAP and Authentication"
> Joe gets a results page showing all the hits
> 
> now without the mod_perl wrapper, Joe "looses his place"... that is,
> htsearch doesn't know anything about our drill down, so after the search
> he is no longer drilled down.  The mod_perl wrapper provides Joe the the
> navigation links that are approprate in the article tree.  Since these
> nav-links change depending on where Joe drilled down, they need to be
> generated dynamically... something that htsearch can't do.
> 

	Well, joe would never lose his place if you used variables in the
pages to track his place.  Which should not be that big a deal really.

	Sumn like
search.php3?cat=x$subcat=y&anothersubcat=whatever&whatever=nothing

You get my general gist here.  will that fit into what you had envisioned
for the search pages?


> Yes, but actually it takes it one step further.  We discussed bookmarking
> your place when you drill down.  I'm talking about being able to bookmark
> an actual search results page.

	Yeah, the above URL will always return to the search results.  The
GET's could include search params or sumn to that effect.  Sumn like
altavista and those guys do.

-Bob 
ccrider@whiterose.net
Systems Administrator for whiterose.net
http://www.whiterose.net