2007/3/14, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><span class="e" id="q_1114f978f18d106c_0">2007/3/13, jamie <<a href="mailto:jamiemcc@blueyonder.co.uk" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">jamiemcc@blueyonder.co.uk</a>>:</span>
</div><div><div><span class="e" id="q_1114f978f18d106c_2"><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><snip> for separate snippets we would like to include a max length
<br>> of the<br>> returned snippet so I'm not sure if a dedicated call for this<br>> would be
<br>> better? Might not matter for a general purpose API like<br>> Wasabi?<br>><br>><br>> Well, generally Wasabi is designed around "sane defaults" (in many<br>> places atleast). Wouldn't it suffice to return a "sanely sized"
<br>> snippet and let the UI trim it to an appropriate size?<br><br>would not be easy for an app though (think of the case when you have<br>multiple search terms highlighted in the snippet)</blockquote></span></div><div>
<br>Good point.
<br></div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I am only suggesting these because they are in important in tracker -
<br>not sure if they matter in Wasabi but could do?
</blockquote></span><div><br>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..?</div></div></blockquote>
<div><br><br>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.<br> </div>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span class="q"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Another thing we do in T-S-T, is get hit count grouped by service (would<br>be slower to get a hit count for each type individually)</blockquote></span><div><br>I assume you use the Tracker method[1] GetHitCount(in s service, in s search_text, out i count) for this.
<br><br>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.
<br><br>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.
</div></div></blockquote><div><br><br>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 :-)<br> </div>
Cheeers,<br>Mikkel<br></div>