[MTOS-dev] Search (Was: should there be an mtos-general? or (shudder) mtos-help?)

[Timothy Appnel]

On Dec 14, 2007 3:51 PM, David Raynes <rayners at apperceptive.com> wrote:

> Depending on how you define 'pluggable'

Pluggable as in:
* Any search engine can be used -- SphinxSearch, MySQL, Plucene,
Google, whatever.
* Can (theoretically) search any object or anything else can get its
hands on. Plugins will have varying degrees of specificity.
* Use the same end point (script) -- ideally the one that MT implements.
* Use the same base tags including tags for navigating results (pagination)
* Most importantly: Don't have to reinvent the entire wheel to
implement a different type of search engine or process.

One of MT's strengths is that you can choose from a number of
different databases, authentication schemes and so on. I'm proposing
that you should be able to plug in the search engine(s) that best
address your needs.

> I would say our SphinxSearch
> plugin could be called just that.  As it stands now, any MT::Object can
> be indexed and searched via sphinx with just a couple lines of code.

...but you have to use SphinxSearch and MySQL.

> One of the items on my pre-1.0 todo list for the plugin is to extract
> the couple functions I wrote into an interface/mixin/whatever similar to
> MT::Taggable or MT::Scorable like I've done for other plugins.

I recall seeing that. I've never been fond of having to inherit a
specific class like MT::Taggable (hidden in MT::Tags) because only the
object author can really make it taggable or scorable or searchable.
There are some hacks around this as you applied, but it shouldn't be
so hard (as in messy). Those methods are tied to one specific search
engine though?

> similar to what is going on with the RTE. :)  As easy as it was to
> insert my own search code into the existing search class, I don't
> imagine it would be much more difficult to toss some registry bits in
> there instead.

Right. Now this is more like what I'm thinking.

<tim/>