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