[Wasabi] FOSDEM conclusions - finalizing the search spec

[Mikkel Kamstrup Erlandsen]

2007/3/14, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
>
> 2007/3/13, jamie <jamiemcc at blueyonder.co.uk>:
>
> > <snip> for separate snippets we would like to include a max length
> > >         of the
> > >         returned snippet so I'm not sure if a dedicated call for this
> > >         would be
> > >         better? Might not matter for a general purpose API like
> > >         Wasabi?
> > >
> > >
> > > Well, generally Wasabi is designed around "sane defaults" (in many
> > > places atleast). Wouldn't it suffice to return a "sanely sized"
> > > snippet and let the UI trim it to an appropriate size?
> >
> > would not be easy for an app though (think of the case when you have
> > multiple search terms highlighted in the snippet)
>
>
> Good point.
>
> I am only suggesting these because they are in important in tracker -
> > not sure if they matter in Wasabi but could do?
>
>
> We could put the preferred snippet length in a session property. Would
> that suffice? You would not be able to set it per-search, but I am not sure
> that is necessary anyway..?
>


I added a session property called hit.snippet.length which defaults to 200
(I don't know what a sane default is). It is specified as a hint only, not
something the search engine is forced to follow.


Another thing we do in T-S-T, is get hit count grouped by service (would
> > be slower to get a hit count for each type individually)
>
>
> I assume you use the Tracker method[1] GetHitCount(in s service, in s
> search_text, out i count) for this.
>
> If you want the same functionality in wasabi you would probably have to
> use a main session and a parallel "counter" session with hit.fields=[].
> Then each time a new hit type is found in the main session you fire of a
> query on that type only in the counter session and use that to get the type
> specific hit count.
>
> Note that this sort of counting is really just a simple version of more
> general information clustering. And if you want to do a more complete
> clustering you will probably not be able to get around firing of parallel
> searches anyway.
>


Apart from the approach I mention I see several ways to get around this, and
I have not found a valid reason for adding it to the spec. Feel free to
enlighten me though :-)

Cheeers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070319/af747233/attachment.htm