On Tue, 2007-03-13 at 21:56 +0800, Fabrice Colin wrote: > 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 ? ;-) > > - "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. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
