1,2) great but Nix the include file, use modules instead.<br><br>It would be much better implemented using modules and search hooks. Otherwise we'll run into another image.inc and the support issues of how to swap out search systems. You will also end up with the inability to use more than once search system at a time which already afflicts core image, database, and cache API's. I'd rather not see that design patter repeated again.<br>
<br>3,4,5) I think flexibility is reason enough without fluff bullet points saying flexibility, flexibility.<br><br>.darrel.<br><br><br><div class="gmail_quote">On Mon, Jun 2, 2008 at 5:14 PM, Doug Green <<a href="mailto:douggreen@douggreenconsulting.com">douggreen@douggreenconsulting.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;">I invite you to join the search group on g.d.o and make this proposal there:<br>
<br>
<a href="http://groups.drupal.org/node/4102" target="_blank">http://groups.drupal.org/node/4102</a><br>
<br>
Please also read all of the blog entries on search that came out of the<br>
MINNESOTA SEARCH SPRINT:<br>
<br>
<a href="http://drupal.org/search/node/MINNESOTA+SEARCH+SPRINT" target="_blank">http://drupal.org/search/node/MINNESOTA+SEARCH+SPRINT</a><br>
<a href="http://www.google.com/search?hl=en&q=MINNESOTA+SEARCH+SPRINT&btnG=Google+Search" target="_blank">http://www.google.com/search?hl=en&q=MINNESOTA+SEARCH+SPRINT&btnG=Google+Search</a><br>
<br>
I hope that you help us with this. We have two visions. We'd like to<br>
make it possible to extend/separate the indexing and/or extend/separate<br>
the UI. Earnest Berry started on separating the UI, but AFAIK nobody<br>
has started work on separating the indexing.<br>
<br>
Thanks!<br>
Doug<br>
<div><div></div><div class="Wj3C7c"><br>
Michael Haggerty wrote:<br>
> I am writing to request comments on a proposed modification to Drupal<br>
> core.<br>
><br>
> Proposal: move the core search functionality in Drupal into an include<br>
> file which can be specified on a per site basis. The actual functions<br>
> used to return search results would not change, this proposed<br>
> modification would simply put them all in a file which can be<br>
> specified within settings.php.<br>
><br>
> There are a number of reasons to consider doing this:<br>
><br>
> 1) The flexibility to specify different search components would<br>
> resolve some potential design deficiencies in the platform as it<br>
> stands now. We have been doing some work integrating the Xapian search<br>
> engine with Drupal. Instead of storing indexed results in the Drupal<br>
> database, we are putting indexed content in Xapian instead. To get<br>
> this to work properly, we have needed to patch core, which represents<br>
> a deficiency both in terms of installation and long term maintenance<br>
> of sites. Modifications to core mean people are working with unique<br>
> distributions of Drupal instead of a common distribution, which are<br>
> more complex to support.<br>
><br>
> 2) This change would not differ significantly from design patterns<br>
> currently in place within the framework. Other core components have<br>
> already adopted this approach. An alternate cache.inc file can be<br>
> specified within settings.php and is used by Robert Douglas' memcache<br>
> module. Settings.php has had the ability to override system settings<br>
> for a long time.<br>
><br>
> 3) In some high traffic scenarios, database throughput becomes a<br>
> bottleneck to the point where Drupal's current search features become<br>
> unusable in the context in which they are deployed. Providing the<br>
> flexibility to specify the underlying search components used for<br>
> Drupal will provide system architects with additional options for<br>
> scaling Drupal sites without losing characteristic features of the<br>
> platform. In the case of Xapian, all database traffic related to<br>
> search features are offloaded into an external database, which could<br>
> represent significant gains in Drupal database throughput.<br>
><br>
> 4) Open source search engines are becoming increasingly sophisticated,<br>
> and there are a number of emerging systems coming of age which<br>
> developers may want to integrate in the future. Developers are often<br>
> loathe to want to hack core, for reasons ranging from inexperience to<br>
> lack of support for core modifications within the Drupal community.<br>
> Being able to modify the underlying search components without the need<br>
> for a core patch greatly simplifies the process of integration and<br>
> likely increases the likelihood developers will want to attempt<br>
> integration projects.<br>
><br>
> 5) Search remains an important component of any Web site. One of the<br>
> great strengths of Drupal is the ability to provide an integrated set<br>
> of tools for managing content. The most significant benefit to<br>
> adopting this approach could be the ability to expand the range of<br>
> options available to implementers at the time a site is being built.<br>
> Providing numerous search engine configuration options with relative<br>
> benefits and drawbacks increases the strength of the platform.<br>
><br>
> Best Regards,<br>
> Michael Haggerty<br>
> _______________________________________________<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>
><br>
<br>
<br>
</div></div><font color="#888888">--<br>
Doug Green<br>
<a href="mailto:douggreen@douggreenconsulting.com">douggreen@douggreenconsulting.com</a><br>
904-583-3342<br>
<br>
Bringing Ideas to Life with Software Artistry and Invention...<br>
<br>
</font></blockquote></div><br>