2007/1/17, Jamie McCracken <<a href="mailto:jamiemcc@blueyonder.co.uk">jamiemcc@blueyonder.co.uk</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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)</blockquote><div> 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? </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.  </blockquote> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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 </blockquote><div>  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> >  - 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</blockquote><div> 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 </div> Cheers, Mikkel </div>