[304] in IS Home Pages

home help back first fref pref prev next nref lref last post

Limits to Infoseek Search?

daemon@ATHENA.MIT.EDU (Kevin M. Cunningham)
Wed Nov 25 15:37:44 1998

Date: Wed, 25 Nov 1998 15:37:46 -0500
To: search@MIT.EDU
From: "Kevin M. Cunningham" <kcunning@MIT.EDU>
Cc: kcunning@MIT.EDU, is-home@MIT.EDU, cavan@MIT.EDU

Howdy Search Gods,

I'm doing some work for the IS Home Page team, and I'm having a little problem.

After consulting with Oliver (who provided syntax tips and an initial draft), I have been trying to expand a simple IS search page (one which only searched files in the "is" locker) to be more all-inclusive. Specifically, I want a user to be able to enter a search string and have Infoseek look for that string in *all* the IS-related files on campus (i.e., all the files in a set of ~30 lockers we've identified, rather than in just the "is" locker).

My draft file (which happens to be in production ;-) is at:

  http://web.mit.edu/is/search/index.html

It seems to work okay, but look at the source code and you'll see the problem: I can only enter about a dozen "URL:..." qp clauses. If I add any more (e.g., one of the ones in the commented area), the search returns a lot of false hits. See, for example, the file:

  http://web.mit.edu/is/search/bad.html

This is identical to the index.html file, except that I took one of the commented qp lines and made it real. If you try a search in index.html (I tried the word "dogs"), you get something reasonable; if you try a search in bad.html, you get a boatload of false hits -- and you seem to get the *same* bad list whatever your search string is.

Suspecting there was a limit to the number of qp lines that could be entered, I created a version with all the "URL:..." strings in a single qp input statement, but the same thing happened (i.e., garbage out when I added more than a certain number of "URL:..." clauses).

It also doesn't seem strongly correlated to *which* "URL:..." clauses I include or omit (although there could be some relationship there...) -- I did try a few different qp statements but didn't notice that one worked and others didn't, although that could be the case... 

In any case, I seem to be hitting some limit related to:

  - a maximum number of separate "URL:..." clauses I can enter

and/or

  - a maximum number of pages I can search in (i.e., the set of pages
    matched by the aggregate of "URL:..." clauses -- to which I then
    apply the search string -- may be too big? is there such a limit?)

Any ideas what's up, or an alternative way to build a custom search that allows a user to find a string in a series of discrete lockers (or even machines)?

Oliver would have followed this up, but he's out Monday/Tuesday of next week and suggested I send for help to this list...

Thanks for your wisdom! I trust I do not "search" in vain...

--Kevin



home help back first fref pref prev next nref lref last post