Okay, here's the thing, I'll respond to both of your writeups, since this is too big for a message:

    This is a good idea, in theory.

First, a technical explaination. Most objects that contain text (writeup, node, user.. for homenode info, superdocs), all inherit type of document. You can see this by going to the nodetype for each of the links above. To get the information for each one we do something like:
SELECT * FROM node LEFT JOIN document LEFT JOIN user
In terms of C++ style inheritance, think of node for the base type of all objects.

Now for a critique of the general idea...There are serveral reasons why a keyword search wouldn't be efficient.
  • First off, the table would get huge quickly. We have over half a million writeups, and at say three good keywords between a writeup, that's a bunch of keywords. To pull even something close out like that would not be good. We wouldn't manage that very well.
  • Second, it would be hard to go and back-index the old tables manually (or even run a script) to index the most common words.
  • Letting users keyword their own writeups wouldn't necessarily be very useful, seeing as we really can't monitor them all. Weighting certain users (the ones with the power), over other users goes kind of against the current power balance.
  • It would be better if we simply did this as a mySQL supported full index search on the document table. It does it in (presumably) the most optimal way for the db provider. I think we'd need to change the table type from what we currently have, and nate was tossing that idea around a while ago. Manual indexing is expensive, and would cause a lot of lag / downtime.
  • Playing with the link mechanism is not something we really want to do for a lot of reasons. Miainly because it's a standard ECore thing, and messing with it is bad.

Yerricde: Outsourcing keywords is alright, but that would mean every writeup would have to be accessed at some point, and then constantly hit to make sure it's updated. It's kind of an icky system to have a dumb client like that. Printable version for google has been tossed around, and it's low on the priority list. We don't NEED to index the site right now, but it would be nice. Heavily relying on external resources may not be looked upon favorably by google. Also, the site is meant to be self contained; that one reason why there are largely no external links.

All in all good ideas, but not really feasible with our current setup. We do need to change the db table types and then full index may be possible.