<div>2007/7/17, Arun Raghavan <<a href="mailto:arunisgod@gmail.com">arunisgod@gmail.com</a>>:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hello On 7/16/07, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>> wrote: > Hi again, > > I have a few suggestions for updates to the xesam search spec. > > * API: > Remove the session properties search.blocking and search.live. These seemed > to cause more confusion than I anticipated. These can be emulated in the > client side lib as far as my scribblings can tell. Anoter solution might > just be better documentation of course... > > Some of you now have actual experience with these, what is your feel? > > The reason for having these properties in the first place was to allow > easier usage of the dbus interface directly - ie not via a client lib. > > What this would mean for the api methods: >  * GetHits should always block until the requested number of hits has been > found or the entire index has been searched (in which case the SearchDone > signal will be emitted too). >  * CountHits should always block until the entire index has been searched >  * No other methods should block <snip> I have no experience with client design, but here's my suggestion: "search.live" should remain, but "search.blocking" should probably be dropped. By definition, a non-live search will cause GetHits() and CountHits() to block till the search is finished.</blockquote><div> By the current standard search.live does not determine this behavior. That is the matter of search.blocking. If search.blocking is false these methods should return immediately with current avail hits or current found number of hits (which will only be final when the entire index has been searched). Or are you talking about the new suggestion? </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">A live search will never block -- both these calls will return with what hits are available. This seems to be a reasonably intuitive model to me.</blockquote><div> Did you mean to post to the list? Please post there if you wanted to, I'll put a reply there too then. The reason for just letting all calls block is that dbus has a build in mechanism for doing async calls (via a callback when the method returns) - thus if we always stick with dbus (and don't want to do a xesam-over-unix-sockets spec in the future) we can safely say that GetHits and CountHits always block. Another important matter might be whether or not to keep the hit set around on the server? Atleast some clients such as deskbar has no need to re-read hits or fetch additional metadata via GetHitData. We could specify that if search.live == false the server is free to drop the hits as soon as they are read with GetHits. This last idea would imply that the GetHitData method only makes sense if search.live == true. If not it should probably return an empty set (dbus has no NULL) or throw an error. Cheers, Mikkel  </div> </div>