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. Cheers. Fabrice _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
