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

[Anil Dash]

Just in the interest of clarifying the use cases here, Tim, what do you see users doing with (for example) command-line search support? That might help others understand what you're advocating from a user-benefit standpoint.

Put differently, I think the priority right now is a performant version of current capabilities, since that's a baseline expectation that all users will have. Similarly, the percentage of users who *don't* make use of the built-in search is vanishingly small. I'm not denying that some very important MT users use search substitutes (and I mean alternate scripts here, not simply Google site search) but as a percentage of users, replacing mt-search wholesale is an uncommon behavior -- do you have more data to suggest otherwise?


----- Original Message -----
From: mtos-dev-bounces at sixapart.com <mtos-dev-bounces at sixapart.com>
To: Fumiaki Yoshimatsu
Cc: mtos-dev at sixapart.com <mtos-dev at sixapart.com>
Sent: Sat Mar 01 11:51:39 2008
Subject: Re: [MTOS-dev] Implementing new MT::App::Search

Spin it as you may, this doesn't seem like my proposal
simply because most of the design objectives have been
discarded. I think Fumiaki has essentially said this now
so we can stop referencing XSearch because it not and
6A is doing their own thing -- not taking something from
the community.

I just don't get why scaling back that there really isn't a
framework at all is the best thing since I did a lot of
"the leg work" figuring out what needs to be in one. I
wrote and released two different search engines using
XSearch and researched a couple more. I may not have
gotten it 100% right, but I gained a lot of insight seems
irrelevant in this effort.

I know there isn't much sense in arguing any of my points
since 6A will do what it wants, but I'd like to clarify what
I had intended with my XSearch proposal and where Fumiaki's
interpretation of that differs for the record.

I don't care so much about the naming or the actual use of
my code as much as the fact the "framework" makes some
significant assumptions -- that this is only for public blog
search (aka mt-search.cgi) and will only be used through
HTTP. I had always intended that search plugins could be
reused or designed for use in MT or in a command-line tool.
Searching data is a core function across the entire system
that I didn't want to artificially limit it to a blog's search function.
Exploring that didn't happen because of time and how hard
that would have been. (MT4 makes that easier than it would
have been in MT3.)

In my proposal I was trying to eliminate the need for any
subclassing and go with the registry/handler that MT4 is
geared. The current XSearch code was written before MT4 so
search plugins are like drivers that can be called from one
common script. Based on Fumiaki's comments, plugins would
subclass MT::App::Search. If you're not using subclass and
are trying to keep what gets loaded up by default to a
minimum, then having specific query interpreters in the base
goes against that. Its not significant, but that is not the
point.

(This is the type of inconsistencies that, lacking
sufficient explanation, guidance  and best practices
documentation that Six Apart has been notoriously bad at
doing, sends mixed messages to new developers as to what is
the right thing to do. The MT code is seen as the standard
to how to code and develop with MT. Not treating it as such
creates a lot of issues. When documentation fails to deliver
in an open source tool the buck stops here at the code. )

I understand that the desire to keep compatibility with the
past query syntax -- I just wish it was optional in the
framework. (The default search implementation that is built
on top of the framework is a different matter.) In my
experience, people gave up on and haven't been using the
search in MT. I really don't know that many people use
anything but more than type in a word or phase. I don't know
if any users know there is more since its never been
documented or made clear on the sites implementing it.

I haven't compared the differences between the MT query
syntax (since I never use it) and Google's, but there are
other query parsers in CPAN that I suspect do. For instance,
Search::QueryParser. Once again I'll make the point that I
think  in embracing open source Six Apart needs to get out
of the habit of doing their own thing and instead embracing
what is already available and in the perl (CPAN) community.
(See: http://appnel.com/code/log/2008/02/not-just-a-license)
The query parser would just be one small step or many more
that need to come.

I thought perhaps I was going to be able offload developing
and maintaining XSearch all by myself when this started, but
I feel the I really need to since what is being developed is
so limited. The funny part will be dancing around the core
implementation like I've had to with the tags engine.

<tim/>

-- 
Timothy Appnel
Appnel Solutions
http://appnel.com/
_______________________________________________
MTOS-dev mailing list
MTOS-dev at sixapart.com
http://www.sixapart.com/mailman/listinfo/mtos-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5242 bytes
Desc: not available
Url : http://www.sixapart.com/pipermail/mtos-dev/attachments/20080301/4341bf0f/attachment.bin