[Wasabi] FOSDEM conclusions - finalizing the search spec

[jamie]

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)


jamie.