[development] Request for Comments: Search.inc

[Michael Haggerty]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080602/e0a3cc70/attachment-0001.htm