[MTOS-dev] Supporting public/private search (was Implementingnew MT::App::Search)

[Fumiaki Yoshimatsu]

Tim, may I ask you to explain a bit more specific about where you see "a lot of bloat in the form of reinvented wheels, specific assumptions and dubious or limited use"?
 
The No.1 goal for the public search has been and is to get it work fine out of the box.  The second, but as big as the first goal, is to allow plugins to extend, enhance and give more power to it.  Of course, to achive the goal No.2, the default behavior can be easily replaced, thus should be simple.
 
The code I have been checked in is required to meet the goal No. 1.  But I believe it also meets the goal No.2, as you can see it actually in action in TagSearch and FreeText.  I must have been overlooking how it can be simpler and easier to be overridden, without compromising the goal No.1.  So, could you please explain a little more about what you are concerned?
 
Fumiaki

________________________________

From: Timothy Appnel [mailto:tim at appnel.com]
Sent: Wed 3/12/2008 8:02 AM
To: Fumiaki Yoshimatsu
Cc: MTOS dev
Subject: Re: [MTOS-dev] Supporting public/private search (was Implementingnew MT::App::Search)



Let me say this differently. I find it discouraging to see so much
getting piled on to MTOS like it is with regards to search.

It's discouraging because the fully pluggable search framework got
passed over because "this is the first iteration, we are not yet 100%
sure how search plugins would want to use the framework"[1] (fine.
fair enough.) with the intent being to implement as "little 'required
to be implemented' items as possible"[1] and yet I'm watching the
check in on search rolling in I feel a lot of bloat is being added in
the form of reinvented the wheels, specific assumptions and dubious or
limited use. This seems inconsistent and contradictory IMHO. Also,
developing a performant search engine should be as much a core
componentcy of MT. (Would MT ever consider writing its own RDBMS?)
Others do it much better so let's just integrate with that.

Under the guise of being a platform with a component architecture, the
core should be getting slimmer (or at least being kept at bay) with
more and more functionality being pushed out as plugins and not
getting any bigger than it already is.

<tim/>

[1] http://www.sixapart.com/pipermail/mtos-dev/2008-February/000668.html

On 3/11/08, Timothy Appnel <tim at appnel.com> wrote:
> I think everything and the kitchen sink is being thrown in there and I
>  wish Six Apart would have stuck with something more simple and basic
>  that could have been extended so a thousand plugins could bloom.
>
>  I also think forcing a user to configure and maintain their system in
>  template/HTML tags is bad for business. (MultiBlog suffers from this
>  same problem.)
>
>  <tim/>
>
>  On 3/11/08, Fumiaki Yoshimatsu <fyoshimatsu at sixapart.com> wrote:
>  > So, what do you (and others) think of this idea, inherited and extended
>  >  slightly from Jay?
>
>
>  --
>  Timothy Appnel
>  Appnel Solutions
>  http://appnel.com/
>


--
Timothy Appnel
Appnel Solutions
http://appnel.com/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.sixapart.com/pipermail/mtos-dev/attachments/20080314/fd17635f/attachment.html