Re: URL summary and how it effects the search engine

[Dean Giberson <dean.giberson@mindless.com>]

Well I'll say this, it greatly changes things ;-)

Making it non-specific to our site increases the difficulty and complexity of the
code. It can be done, of course everything can be done. Creating the site
specific version would be easier for now. I could complete the task then change
it at a later time as a patch. Otherwise I think you will be waiting for quite
some time for an important part of the project. If I make it specific at first
then change it, you all could get going and I could code in parallel with you.

How does this sound?

Aaron Turner wrote:

> Dean, is this a problem?  Now is the time to speack up. :) There is one
> critera that isn't critical, but would be very nice- that your
> implimentation of this isn't specific to our site.  That way we can send
> in your work as a patch to the htdig group and have it incorporated into
> the main tree.
>
> One idea is to have htsearch accept a parameter called "unique" which
> accepts a space delimited list of words which is the name(s) of the
> variables which establish what is a unique document.  In our case
> unique="type p" would be passed to htsearch.
>
> -Aaron
>
> On Sat, 17 Jul 1999, Jason Pincin wrote:
>
> > type=6&p=1 and type=7&p=1 are two different documents.
> >
> > So your unique value will be a combination of those two variables.
> >
> > 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.
> >
>
> --
> Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
> Linux Knowledge Base Organization  http://linuxkb.org/
> Because world domination requires quality open documentation.