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