[Wasabi] FOSDEM conclusions - finalizing the search spec
Fabrice Colin
fabrice.colin at gmail.com
Tue Mar 13 15:56:57 EET 2007
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 ? ;-)
- "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..." ?
- "These signals are only used if the session property search.blocking is true."
Again, shouldn't it be "if search.live is true" ?
- GetState
if the first string is "FULL_INDEX", shouldn't the second string
always be "100" ?
- 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)".
- 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 ?
- properties and field names
You may want to clarify what differences, if any, there are between
properties and
field names.
Cheers.
Fabrice
More information about the xdg
mailing list