Simple search API proposal, take 2

[Mikkel Kamstrup Erlandsen]

2007/1/17, Jamie McCracken <jamiemcc at blueyonder.co.uk>:
>
> Mikkel Kamstrup Erlandsen wrote:
> > Proposed Updates for the Simple API:
> > --------------------------------------------------------------
> >
> >  - Change GetHitProperties (in s query_handle, in i offset, in i limit,
> > in as props, out a{sa{sas}}) to GetHits(in s query_handle, int i offset,
> > int i limit, in as props, out aas) where the output is on the form
> > [[HitId, props in rq. order], [HitId, props in rq. order], ...]. This
> > seemed to be the consensus of the recent discussions.
>
> "aav" would be better than "aas" as some metadata will have muliple
> values (email:to, email:cc etc)



Whether or not to use a variant is a tricky question. I would prefer using a
return value like "aaas" in all cases instead. I have no arguments except
gut feeling though. Variants would allow for values like file:size to be
returned as integers though. This logic might equally well be pushed to the
toolkit bindings instead though.

What do you guys think?


Although our rdf query output has moved from "a{ss}" to "aas" in the
> past, we will be shortly going to "aav" to handle the above cases better.
>
>
> >
> > Stuff to Think About:
> > ---------------------------------------------------
> >  - Ordering : Is it fair to expect ordered results from the indexer at
> > all? From the new return type of of GetHits I would assume that the
> > result set was ordered. This may be fine in the simple api, but if we
> > want to use the same  data structures in the live api it is beginning to
> > look weird. Hits with a really high score might be added after all hits
> > have otherwise been retrieved. Also in the new query xml language you
> > can actually specify an ordering (and grouping) - does this make sense
> > at all?
>
> we can ignore the hit score race condition.
>

The sort order should always include rank. If a result was asked to be
> ordered by say File:Size then the result set should be ordered by
> File:Size and then rank (so files with the same size will be ordered by
> rank). Of ocurse if no order by is specified then rank alone should be
> used




>
> >  - Moving ShowConfiguration() to
> > org.freedesktop.search.ui.ShowConfiguration()? A drawback is that we
> > can't guarantee that search.simple and search.ui is owned by the same
> > d-bus services. If we had a search.ui we could also add a
> > search.ui.ShowSearchTool(in s search_string).
>
> a separate ui interface might be more apt


Ok. SP how about a search.ui interface with the methods:

 - ShowConfiguration (in s toolkit_hint, out s error_msg)
toolkit_hit is a string to hint which toolkit to use. "gtk", "qt", "fox",
"fltk", "cocoa". If error_msg!="" an error occured.

- ShowSearchTool (in s default_search_string, in s toolkit_hint, out s
error_message)
default_search_string is a string to set in the ui when it is spawned

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070118/10eed09d/attachment.htm