2007/7/19, Jos van den Oever <<a href="mailto:jvdoever@gmail.com">jvdoever@gmail.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 2007/7/16, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>>: > 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 > > * Query Language: > I suggest we remove the "type" attributeon the query element. You can just > specify the Category- or StoredAs fields in you selectors. I completely agree on all suggestions. One more suggestion: the minimal interval between result signals should be sane or settable.</blockquote> <div> Valid point. To avoid signal spamming I take it. How about a session property  hit.batch.size that is an integer determining how many hits the server should collect before emitting HitsAdded. In case the entire index has been searched but < hit.batch.size hits has been found HitsAdded should be emitted(num_hits) right before SearchDone. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On the topic of remembering the hits. In ideal world, the server could be clever and get the right file from the hit number. In reality, this is quite hard. Atm the server should keep a vector with uris internally. I think we should allow the server to have a sane maximum of hits that are retrievable. E.b. CountHits might return 1 million, but you would only be able to retrieve the first 100k.</blockquote><div> This makes sense given that  the scoring algorithms on servers are good enough. But judging by the extraordinary amount of talent we have in the server-side dev camp this is no problem of course :-) How about a read-only session property search.maxhits? We could specify that in order to be xesam compliant this value must be > 1000 or something - just so that apps wont have to sanity checks galore. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This is actually a scalability issue. We should allow the search to modify the vector when the hit has not yet been retrieved and only guarantee reproducibility for hits that were retrieved already. In combination with a maximum history size this would handle most performance problems.</blockquote><div> Yeah, we are handling the exact same problems at work :-) I think  we have solved it here (atleast up to 100M or so), but it is not exactly client side software... </div> Cheers, Mikkel </div>