Re: URL summary and how it effects the search engine

[Jason Pincin <jpincin@ashtech.net>]

The high-lighting will be done, but it will be done in article.php3.
Render.php3 is only going to be a couple line program that when it see's a
type=6, will just do an <? include /articles/article.php3 ?> which will in
turn have access to all of the variables passed into render.php3, and
article.php3 will parse the word list, highlighting all of them.

Jason



On Fri, Jul 16, 1999 at 03:57:06PM -0700, Aaron Turner wrote:
> 
> After a nice talk, Jason and I came to an agreement on how to work the
> URL's so that he can do what he wants and the search engine can handle
> them without us re-writing the whole bloddy thing.  
> 
> There is a global PHP page "render.php3" that lives in various
> directories.  The location of render.php3 tells it what/how to render
> content to the user.  The only thing of real interest for this, is the
> fact that all articles will live as:
> 
> http://<someserver>/articles/render.php3
> 
> render.php3 takes the following arguments:
> 
> o - The object position.  This is in essense the drill down.  Stand-in
> replacement for the old 'c' variable.
> 
> p - The pointer to the actual article.  This is unique for each article
> regardless of it's origin.
> 
> type - This tells render.php3 how to render the article.  a type=6 denotes
> internal content, and a type=7 is for external documentation (like the
> LDP).
> 
> dN, where N is an integer >= 0 - these are the versioning dependancies
> arguments.  Will not be implimented right now.
> 
> each article will have a URL in the following format:
> 
> /articles/render.php3?o=a.b.c.d&p=X&type=Y
> 
> htsearch (the htdig CGI) will be passed a number of variables.  Noteably:
> 
> restrict=/articles/render.php3?o=a.b.c.d
> 
> This will have the effect of limiting the search to articles in the
> a.b.c.d branch or below.  
> 
> IF the user wishes to limit their searches to LKBP internal docs then:
> 
> exclude=&type=7
> 
> IF the user wishes to limit their search to external docs then:
> 
> exclude=&type=6
> 
> IF the user wishes to search both internal and external docs then exclude
> will be unset.
> 
> Dean, if I understand the htdig developers correctly, the restrict and
> exclude parameters will have already sorted out bad hits.  Hence you
> should be able to limit your matching to &p=X as the unique identifier.
> [Jason, am I'm correct in assuming that &type=6&p=1 and &type=7&p=1 are
> the same article, but that they're rendered differently?  ie, the type
> parameter does not effect the uniqueness of p.  If that is not the case,
> it isn't a big deal, but Dean and I need to know.]
> 
> Anyways, once htdig 3.2 comes out, htsearch will be able to use regexps to
> evaluate the contents of restrict and exclude.  At that point will we be
> able to support the &dN set of arguments.
> 
> Last, Jason, don't forget that Search.pm re-writes each 'hit' URL to
> include an additional parameter 'words'.  render.php3 should take this
> comma delimted (I use commas to allow phrases in the future) list and
> highlight them in the article, by changing their <font color> to red or
> something.
> 
> --
> Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
> Linux Knowledge Base Organization  http://linuxkb.org/
> Because world domination requires quality open documentation.