]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/todo/different_search_engine.mdwn
Merge commit 'upstream/master' into pub/master
[git.ikiwiki.info.git] / doc / todo / different_search_engine.mdwn
index a6364b43268bd4ba8b2094122cdd8fa72680d44d..2f309dea56e665433e55330ffb0f007e216776a2 100644 (file)
@@ -1,4 +1,6 @@
-After using it for a while, my feeling is that [[hyperestraier]], as used in
+[[done]], using xapian-omega! --[[Joey]]
+
+After using it for a while, my feeling is that hyperestraier, as used in
 the [[plugins/search]] plugin, is not robust enough for ikiwiki. It doesn't
 upgrade well, and it has a habit of sig-11 on certain input from time to
 time.
 the [[plugins/search]] plugin, is not robust enough for ikiwiki. It doesn't
 upgrade well, and it has a habit of sig-11 on certain input from time to
 time.
@@ -31,35 +33,25 @@ Possibilities:
   written on the page would be indexed. Not text generated by directives,
   pulled in by inlining, etc. There's something to be said for that. And
   something to be said against it. It would also get markdown formatted
   written on the page would be indexed. Not text generated by directives,
   pulled in by inlining, etc. There's something to be said for that. And
   something to be said against it. It would also get markdown formatted
-  content, mostly, though it would still need to strip html.
+  content, mostly, though it would still need to strip html, and also
+  probably strip preprocessor directives too.
 * `sanitize` - Would get the htmlized content, so would need to strip html.
 * `sanitize` - Would get the htmlized content, so would need to strip html.
-  Preprocessor directive output would be indexed.
+  Preprocessor directive output would be indexed. Doesn't get a destpage
+  parameter, making optimisation hard.
 * `format` - Would get the entire html page, including the page template.
   Probably not a good choice as indexing the same template for each page
   is unnecessary.
 
 * `format` - Would get the entire html page, including the page template.
   Probably not a good choice as indexing the same template for each page
   is unnecessary.
 
-Currently, a filter hook seems the best option.
-
 The hook would remove any html from the content, and index it.
 The hook would remove any html from the content, and index it.
-It would need to add the same document data that omindex would, as well as
-adding the same special terms (see
-http://xapian.org/docs/omega/overview.html "Boolean terms").
-
-(Note that the U term is a bit tricky because I'll have to replicate
-ominxes's hash_string() to hash terms > 240 chars.)
+It would need to add the same document data that omindex would.
 
 The indexer (and deleter) will need a way to figure out the ids in xapian
 of the documents to delete. One way is storing the id of each page in the
 ikiwiki index.
 
 The other way would be adding a special term to the xapian db that can be
 
 The indexer (and deleter) will need a way to figure out the ids in xapian
 of the documents to delete. One way is storing the id of each page in the
 ikiwiki index.
 
 The other way would be adding a special term to the xapian db that can be
-used with replace_document_by_term/delete_document_by_term. omindex uses
-U<url> as a term, and I guess I could just use that, and then map page
-names to urls when deleting a page  ... only real problem being the
-hashing; a collision would be bad.
-
-At the moment, storing xapian ids in the ikiwiki index file seems like the
-best approach.
+used with replace_document_by_term/delete_document_by_term. 
+Hmm, let's use a term named "P<pagename>".
 
 The hook should try to avoid re-indexing pages that have not changed since
 they were last indexed. One problem is that, if a page with an inline is
 
 The hook should try to avoid re-indexing pages that have not changed since
 they were last indexed. One problem is that, if a page with an inline is
@@ -67,7 +59,8 @@ built, every inlined item will get each hook run. And so a naive hook would
 index each of those items, even though none of them have necessarily
 changed. Date stamps are one possibility. Another would be to avoid having
 the hook not do any indexing when `%preprocessing` is set (Ikiwiki.pm would
 index each of those items, even though none of them have necessarily
 changed. Date stamps are one possibility. Another would be to avoid having
 the hook not do any indexing when `%preprocessing` is set (Ikiwiki.pm would
-need to expose that variable.)
+need to expose that variable.) Another approach would be to use a
+needsbuild hook and only index the pages that are being built.
 
 #### cgi
 
 
 #### cgi