2007/3/13, Fabrice Colin <[EMAIL PROTECTED]>:
On 3/13/07, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]> wrote: > Please give http://freedesktop.org/wiki/WasabiSearchLive a > good look before we set this in stone. It is the last call if you have any > objections - I really mean it this time. Anything from critisizing the > fundamental structure down to nitpicking on the session property names is > welcome. > There's a couple of things I am not clear about : - "search.blocking : Whether or not calls will block until the requested items are available." Do you really mean this ? Should NewSearch block ad vitam eternam if there are no results for the given query ? ;-)
Ok , that was a bit unclear :-) What I'm trying to say is: "Whether or not the methods GetHits and CountHits will block until the requested items are available or the entire index has been searched" - which is also reflected on the wiki now. - "CountHits (in s search, out i count) Returns the current number of
found hits. If search.blocking==true this call blocks until the index has been fully searched." Shouldn't this read "if search.live==false this call blocks..." ?
No. search.live and search.blocking are not the same. search.live just specifies that the search should "persist" and update the result set via the signals described. search.blocking determines whether or not the calls GetHits and CountHits return immediately with partial results or only when the result is fully available. - "These signals are only used if the session property search.blocking is
true." Again, shouldn't it be "if search.live is true" ?
Right. Fixed. - GetState
if the first string is "FULL_INDEX", shouldn't the second string always be "100" ?
I was a bit in a rusj when I wrote that part... here are better descriptions of the states: IDLE : the search engine is doing nothing UPDATE : the search engine is updating the index FULL_INDEX: the search engine is building an index from scratch So, to answer your question - no :-) Wiki updated. - signal HitsAdded
is count the number of new hits, or the new number of hits ? I assume the latter since the example at the bottom shows a call to "GetHits(session, count)" after receiving "HitsAdded(count)".
Right. I have tried to clarify this. - signal StateChanged
An example would be welcome here. For indexers that monitor sources, eg monitor the filesystem with inotify, the state will switch between UPDATING and IDLE and/or FULL_INDEX very often. Is the indexer supposed to send a signal every time ?
True - this is unclear. I've added a note saying that for "negligible" tasks (re-index a single file or such) the signal need not be fired. - properties and field names
You may want to clarify what differences, if any, there are between properties and field names.
Yeah, I might have spend too much time fiddling about with this to see where the subtleties are anymore. I have updated the wiki with clarifications. - There where some cruft left from previous iteratiosn that blurred the picture too. I took the liberty to rename the session property hit.properties to hit.fields to make matters more clear. I hope it is ok. I hope it is better now. Please check that I've catered to your remarks. Cheers, Mikkel
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
