[MTOS-dev] Implementing new MT::App::Search

[Mark Carey]

On Sat, Mar 1, 2008 at 7:29 PM, Timothy Appnel <tim at appnel.com> wrote:
>  I'd don't have any specific research other than my own observation in
>  working with clients, talking to user and other MT users, but to say
>  the number of those who don't is vanishingly small?

While true, I think Anil is correct, but only if you are looking at
the entire MT user base.  Looking at it that way, the vast majority
are small personal blogs with few entries.  And because they have so
few entries, mt-search doesn't really pose much of an issue to them.
On the other hand, if you looks at "clients", which though the
minority of the universe, are bigger in terms of database size and
traffic, the vast majority of this subset likely have dumped mt-search
in favor of another script or 3rd-party site-search tool -- because
they really don't have much choice in the matter.  (The primary reason
I created Fast Search is because mt-search was essentially crashing my
dedicated server)

All of that said, both Anil and Tim are right, it just depends on your
perspective.  There are two different user groups here, who have had
very different experiences with mt-search.  The tough question is:
given these differences, what should the solution look like?  If you
have to decide between the the highest performance solution and a
lesser one that provides backward compatibility (maybe such a choice
isn't necessary, I don't know) -- then I think the choice should be
for performance.  In the case of search, legacy search forms/templates
can always fallback to the legacy search -- as mentioned above, those
users are the smaller sites that probably don't have a problem with
the legacy search anyway.

I agree with the general notion that search performance should be top
priority.  But I like idea of Tim's framework too, and it sure would
be nice to have both. ;)

-Mark