2007/1/25, Magnus Bergman <<a href="mailto:magnus.bergman@observer.net">magnus.bergman@observer.net</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Thu, 25 Jan 2007 09:44:53 +0100 "Mikkel Kamstrup Erlandsen" <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>> wrote: > 2007/1/24, Magnus Bergman <<a href="mailto:magnus.bergman@observer.net"> magnus.bergman@observer.net</a>>: > > > > On Sun, 21 Jan 2007 01:41:47 +0100 > > "Mikkel Kamstrup Erlandsen" <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com </a>> wrote: > > > > > Here's an actual proposal for unifying the simple and live apis. > > > I'm not saying that we really really should do this, just that it > > > is doable, and it still allows for quite simple use cases (see > > > below). It is actually very much in spirit with Magnus' very > > > first proposal a while back. Praise late insight :-) > > > > > > == Unified API Proposal == > > > > > > NewSession (out s session) > > >  * > > > > > > SetProperty (in s session, in s prop, in s val) > > >  * Set a property on the session. Prominent ones are > > >    - live : whether or not to be in live mode. Default false. > > >    - hit.properties : semi colon separated list of field names. > > > Default "uri". > > > > Does the (potentially) expensive properties need to be included in > > hit.properties, or are they considered special? > > > > 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. OK. You mentioned cases there it can be relevant for the search engine to know which hit properties will be requested before the search starts (which is the reason why they are set with hit.properties). Isn't it possible that the same goes for the expensive properties (that less resources could be used it was known in advance that the expensive property would never be requested)? (Not that I care much of this detail, I just thought I should mention in.)</blockquote><div> Yeah, we could include a "hit.properties.extended" property which was not included in the result set, but was a hint/warning to the search engine about the client being likely to request these attributes via GetHitData. I don't think it should be mandatory though, just an optional hint.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > > > > GetProperty (in s session, in s prop) > > >  * > > > > > > CloseSession (in s session) > > >  * Close the session and all child searches > > > > > > Search (in s session, in s query_xml, out s search) > > >  * Start a new search from a query > > > > > > CountHits (in s search, out i count) > > >  * Returns the current number of found hits. If live=false this > > > call blocks until the index has been fully searched. > > > > > > GetHits (in s search, in i num, out aav hits) > > >  * Return num hits. If live=false this call blocks until there is > > > num hits available or the index has been fully searched. > > >    The client should keep track of each hit's serial number if it > > > want to use GetHitData later. > > > > > > GetHitData (in s search, in ai hit_ids, in as properties, out aav > > > hit_data) > > >  * Get hit metadata. Intended for snippets or modified hits. > > > hit_ids are serial numbers as obtained from GetHits. > > > > The GetHits/GetsHitsData functions was a quite elegant solution, I > > must say. But one thing isn't clear to me. Can any property be > > requested with GetHitsData (restarting the search if needed)? Or > > just those that are included in hit.properties? Or perhaps those > > that are either expensive *or* included in hit.properties? > > > 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. > > Perhaps the "current hit_id" (the implicit offset used in GetHits) > could > > be a property of the search? > > > 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. Yes, this is also just a small detail. If it's considered needed it can easily be added later anyway. > > > CloseSearch (in s search) > > >  * Close and free a search. > > > > > > SIGNAL HitsAdded (in i count) > > > SIGNAL HitsRemoved (in ai hit_ids) > > > SIGNAL HitsModified (in ai hit_ids) > > > > All in all I'm very happy with this proposal. > > > > Ok, good. I updated the live proposal with most of your feedback. Another thing I thought of: The search function of the simple API (possibly) took a "simple end user QL" string instead of XML. Has this idea been dropped or just forgotten? Personally I'm in favor of dropping it and create XML from "simple end user QL" on the client side, possibly using a library. </blockquote></div> The xml language proposed at <a href="http://wiki.freedesktop.org/wiki/WasabiQueryLanguage">http://wiki.freedesktop.org/wiki/WasabiQueryLanguage</a> allows for embedding of user queries. Here's a copy-paste of the example from the page: <pre> <request> <userQuery> type:music hendrix </userQuery> </request></pre> I think this should be enough. It would be trivial for language bindings to provide a helper method UserSearch("type:music hendrix") wrapping the string in the appropriate xml, Cheers, Mikkel