2007/3/14, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]>:

2007/3/13, jamie <[EMAIL PROTECTED]>:

> <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
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg

Reply via email to