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

[Jay Allen]

On Thu, Feb 28, 2008 at 4:23 AM, Fumiaki Yoshimatsu
<fyoshimatsu at sixapart.com> wrote:
> I checked in today refactored MT::App::Search to the Release-30 branch.

This is truly a momentous and happy occasion.  MT-Search is dead!
Long live MT-search!

>  It:
>  * does LIKE query
>  * supports limit/offset
>  * supports most of the config directives related to search
>  * is extensible via registry, for what to search
>  * is extensible by inheriting from the base class to change how to
>  search

This sounds fantastic except for one thing: I would love to see a far
better system for controlling exactly what a search can/will return.
The main problem with IncludeBlogs/ExcludeBlogs/NoOverride is that
there is no way for you to protect one or more blogs from being
searched **by the public** and yet allow them to be searched from the
blog itself.  That is, if a blog can't be publicly searched, it can't
be searched.

This is particularly troublesome in installations that host both
public and private, protected blogs.  To stop the content from the
protected blogs from showing up, you need to exclude them in the
config but in doing so, you cannot use search on that blog, which also
makes tags nearly worthless.

I'm sure that there are a number of ways to implement it but I'm
thinking of "search keys".  In essence, each blog would have a search
key which, when used in the search form, would indicate to the system
to only return content from that blog.  This could be implemented in
the search form in the default templates with an MTBlogSearchKey tag.

Then, in the System Overview config, a "Search" tab would be created
and on that page you could specify collections of blogs to be search.
The system would generate and display a search key for each collection
which could be used in place of the MTBlogSearchKey tag in the search
form parameter.  A search from such a form would return results only
from the collection.

Of course, the system above could be layered on top of the existing
directives for backwards compatibility.

I'd love to hear some thoughts on the subject from you all.

>  This is just a start and I am planning to implement the following
>  (hopefully).
>
>  * Recover tag search support

Fumiaki, if you have the ability, please keep the framework compatible
with tag intersections.  I believe they were supported on the back
end.

>  * Recover newcomment search support

Is this even necessary any more?  Does anyone use this?  I implemented
this only because at the time (Oct 2001) there were no tags which
would allow you to list new comments on the blog nor in the UI.
That's clearly not the case now or any time in the last 5-6 years.

If I'm wrong, please correct me, but I'm pretty sure this is about as
useful as an appendix.

>  * Framework for freetext index support that can leverage the feature in
>  the DBMS
>  * Memcache caching support to keep away from throttling while avoiding
>  DoS
>  * Ajax-y way to retrieve offset of search results in the browser's
>  background

This is so incredibly welcome.  Thank you for tackling it Fumiaki.

Jay