[Wasabi] FOSDEM conclusions - finalizing the search spec

[Mikkel Kamstrup Erlandsen]

2007/3/13, Fabrice Colin <fabrice.colin at gmail.com>:
>
> On 3/13/07, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070313/da855522/attachment.htm