[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: URL summary and how it effects the search engine
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.