2007/1/24, Magnus Bergman <<a href="mailto:magnus.bergman@observer.net">magnus.bergman@observer.net</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sun, 21 Jan 2007 01:41:47 +0100<br>"Mikkel Kamstrup Erlandsen" <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>> wrote:<br><br>> Here's an actual proposal for unifying the simple and live apis. I'm
<br>> not saying that we really really should do this, just that it is<br>> doable, and it still allows for quite simple use cases (see below).<br>> It is actually very much in spirit with Magnus' very first proposal a
<br>> while back. Praise late insight :-)<br>><br>> == Unified API Proposal ==<br>><br>> NewSession (out s session)<br>> *<br>><br>> SetProperty (in s session, in s prop, in s val)<br>> * Set a property on the session. Prominent ones are
<br>> - live : whether or not to be in live mode. Default false.<br>> - hit.properties : semi colon separated list of field names.<br>> Default "uri".<br><br>Does the (potentially) expensive properties need to be included in
<br>hit.properties, or are they considered special?</blockquote><div><br><br>In the updated proposal the expensive properties are requested via the GetHitData method. Here you don't have to list the desired properties in
hit.properties.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> GetProperty (in s session, in s prop)<br>> *<br>
><br>> CloseSession (in s session)<br>> * Close the session and all child searches<br>><br>> Search (in s session, in s query_xml, out s search)<br>> * Start a new search from a query<br>><br>> CountHits (in s search, out i count)
<br>> * Returns the current number of found hits. If live=false this call<br>> blocks until the index has been fully searched.<br>><br>> GetHits (in s search, in i num, out aav hits)<br>> * Return num hits. If live=false this call blocks until there is num
<br>> hits available or the index has been fully searched.<br>> The client should keep track of each hit's serial number if it<br>> want to use GetHitData later.<br>><br>> GetHitData (in s search, in ai hit_ids, in as properties, out aav
<br>> hit_data)<br>> * Get hit metadata. Intended for snippets or modified hits. hit_ids<br>> are serial numbers as obtained from GetHits.<br><br>The GetHits/GetsHitsData functions was a quite elegant solution, I must
<br>say. But one thing isn't clear to me. Can any property be requested<br>with GetHitsData (restarting the search if needed)? Or just<br>those that are included in hit.properties? Or perhaps those that are<br>either expensive *or* included in
hit.properties?</blockquote><div><br>Any property can be requested via GetHitData. That was the idea at least. I documented this on <a href="http://wiki.freedesktop.org/wiki/WasabiSearchLive">http://wiki.freedesktop.org/wiki/WasabiSearchLive
</a> now. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Perhaps the "current hit_id" (the implicit offset used in GetHits) could
<br>be a property of the search?</blockquote><div><br>Well, then the Search object/handle would need properties anyway. Would it not be easier to put such counting functionality in a language/platform binding? It can easily be calculated by the client anyway.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> CloseSearch (in s search)<br>> * Close and free a search.<br>
><br>> SIGNAL HitsAdded (in i count)<br>> SIGNAL HitsRemoved (in ai hit_ids)<br>> SIGNAL HitsModified (in ai hit_ids)<br><br>All in all I'm very happy with this proposal.<br></blockquote></div><br>Ok, good. I updated the live proposal with most of your feedback.
<br><br>Cheers,<br>Mikkel<br>