[development] Request for Comments: Search.inc

[Ken Rickard]

Please open an issue for this (if there isn't one already) and move the
discussion there.

Personally, without any deep research, I like this idea.  Much like
cache.inc in D6.

- Ken



On Mon, Jun 2, 2008 at 2:47 PM, mark burdett <mfburdett at gmail.com> wrote:

> The main thing I would like to see is splitting search module into a
> base search api module and a node search module.  The latter could be
> disabled and replaced with any number of alternative node search
> modules.  If it's possible for Xapian search to use the search api,
> then this might be an even easier solution -- just turn modules on and
> off, no need to modify a settings file.
>
> --mark
>
> On Mon, Jun 2, 2008 at 11:24 AM, Michael Haggerty
> <mhaggerty-lists at trellon.com> wrote:
> > I am writing to request comments on a proposed modification to Drupal
> core.
> > Proposal: move the core search functionality in Drupal into an include
> file
> > which can be specified on a per site basis. The actual functions used to
> > return search results would not change, this proposed modification would
> > simply put them all in a file which can be specified within settings.php.
> > There are a number of reasons to consider doing this:
> > 1) The flexibility to specify different search components would resolve
> some
> > potential design deficiencies in the platform as it stands now. We have
> been
> > doing some work integrating the Xapian search engine with Drupal. Instead
> of
> > storing indexed results in the Drupal database, we are putting indexed
> > content in Xapian instead. To get this to work properly, we have needed
> to
> > patch core, which represents a deficiency both in terms of installation
> and
> > long term maintenance of sites. Modifications to core mean people are
> > working with unique distributions of Drupal instead of a common
> > distribution, which are more complex to support.
> > 2) This change would not differ significantly from design patterns
> currently
> > in place within the framework. Other core components have already adopted
> > this approach. An alternate cache.inc file can be specified within
> > settings.php and is used by Robert Douglas' memcache module. Settings.php
> > has had the ability to override system settings for a long time.
> > 3) In some high traffic scenarios, database throughput becomes a
> bottleneck
> > to the point where Drupal's current search features become unusable in
> the
> > context in which they are deployed. Providing the flexibility to specify
> the
> > underlying search components used for Drupal will provide system
> architects
> > with additional options for scaling Drupal sites without losing
> > characteristic features of the platform. In the case of Xapian, all
> database
> > traffic related to search features are offloaded into an external
> database,
> > which could represent significant gains in Drupal database throughput.
> > 4) Open source search engines are becoming increasingly sophisticated,
> and
> > there are a number of emerging systems coming of age which developers may
> > want to integrate in the future. Developers are often loathe to want to
> hack
> > core, for reasons ranging from inexperience to lack of support for core
> > modifications within the Drupal community. Being able to modify the
> > underlying search components without the need for a core patch greatly
> > simplifies the process of integration and likely increases the likelihood
> > developers will want to attempt integration projects.
> > 5) Search remains an important component of any Web site. One of the
> great
> > strengths of Drupal is the ability to provide an integrated set of tools
> for
> > managing content. The most significant benefit to adopting this approach
> > could be the ability to expand the range of options available to
> > implementers at the time a site is being built. Providing numerous search
> > engine configuration options with relative benefits and drawbacks
> increases
> > the strength of the platform.
> > Best Regards,
> > Michael Haggerty
> > _______________________________________________
> > Michael Haggerty | Managing Partner | Trellon, LLC
> >
> > web www.trellon.com | email mhaggerty at trellon.com
> > tel 240 643 6561 | aim haggerty321
> >
>



-- 
Ken Rickard
agentrickard at gmail.com
http://ken.therickards.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080602/a90c8d97/attachment.htm