[Wasabi Proposal] Live search API

Thu Jan 25 12:40:15 PST 2007

2007/1/25, Magnus Bergman <magnus.bergman at observer.net>:
>
> On Thu, 25 Jan 2007 09:44:53 +0100
> "Mikkel Kamstrup Erlandsen" <mikkel.kamstrup at gmail.com> wrote:
>
> > 2007/1/24, Magnus Bergman <magnus.bergman at observer.net>:
> > >
> > > On Sun, 21 Jan 2007 01:41:47 +0100
> > > "Mikkel Kamstrup Erlandsen" <mikkel.kamstrup at gmail.com> 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.)

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.

> >
> > > > 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
> > http://wiki.freedesktop.org/wiki/WasabiSearchLive 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.
>

The xml language proposed at
http://wiki.freedesktop.org/wiki/WasabiQueryLanguage allows for embedding of
user queries. Here's a copy-paste of the example from the page:

<request>
  <userQuery>
    type:music hendrix
  </userQuery>
</request>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070125/1fcfd5aa/attachment.htm 