[Wasabi] FOSDEM conclusions - finalizing the search spec

jamie jamiemcc at blueyonder.co.uk
Tue Mar 13 16:41:48 EET 2007

On Tue, 2007-03-13 at 21:56 +0800, Fabrice Colin wrote:
> 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.

On top of all that if this API were to be usable in our tracker GUI we
would need the following:

1) in tracker the service type being searched is mandatory - I would
prefer it to be a session property or even better a param in the
NewSearch method. If it remains part of the xml then that bit should be
mandatory in the xml schema/dtd

2) GetHits/GetHitData

There are two use cases as far as tracker goes:

a ) if i need metadata for all hits then it will always be quicker to
have them in GetHits 

b) for things like our tile we need to fetch extra metadata for a single
hit so GetHitData would only ever be used for a single hit not multiple
ones - would be easier for us if that was changed to:

GetHitData (in s ID, in as fields out av values)

(I cant think of a single case where we would want to get metadata
*separately* for more than one hit at a time)

3) for separate snippets we would like to include a max length of the
returned snippet so I'm not sure if a dedicated call for this would be
better? Might not matter for a general purpose API like Wasabi?

I dont think we can freeze the api until we have a working
implementation (which may uncover the need for more changes) - I plan on
implementing it in tracker next month.

things still blocking implementation:

1) list of applicable metadata names - I would suggest a mandatory set
(IE metadata supported by all) and an optional set (this would always
return NULL if not supported)

2) list of applicable service types (emails, files, conversations etc)


More information about the xdg mailing list