Minnesota Search Sprint
On the web:
May 9, 2008 - May 11, 2008
Some of the things I’d like to achieve:
- The steps that are taken during indexing (and later during query parsing) should be made atomic and chained, similar to input formats and filters. This would combine the preprocess hook with text transformations that already happen (stripping punctuation, lowercase, etc.) I’ve considered building a prototype with the current filter system.
- hook_search(‘name’) needs to return more metadata. Ideally modules could provide multiple searches and allow themselves to be configured (such as adding elements to the search form, or defining their own search form). Perhaps other $ops are needed.
- The type column in all search tables should be removed and each type should maintain its own tables.
- The keywords should not persist throughout the request in the form of a string, but rather an object that handles adding fields, removing fields, cloning etc. I have such an object that is very near general purpose use in the ApacheSolr module.
- The service of tracking which nodes need indexing should be generalized so that other node indexing modules can use the same code to track which nodes they need to index. There is code (less elegant than the previously mentioned query builder) in the ApacheSolr module that does this.
- do_search needs refactoring. Possibly needs to be broken into two or more phases that include callbacks to the the caller, or a query object that has defined query building setters. Sending in snippets of raw SQL for multiple phases is a bit confusing.





GroupLens
You might also consider touching base with the GroupLens folks … they do a lot of interesting research that might prove complementary to the relationship that you’re building with them.
Here’s a 2005 interview w/ some background info …
http://connect.educause.edu/blog/mpasiewicz/aninterviewwiththeunivers/17...
Post new comment