[Xesam] SearchDone vs server side errors

[Arun Raghavan]

On Tue, Apr 22, 2008 at 1:21 AM, Mikkel Kamstrup Erlandsen
<mikkel.kamstrup at gmail.com> wrote:
<snip>
> I am having second thoughts on this.
>
> Since a normal SearchDone does not necessarily mean that the search has
> stopped running in case of a live session. On the other hand a SearchFailed
> signal (or what ever we call it) will probably always mean that search is
> dead (the question is whether the client needs to call CloseSearch on it is
> open then).

I think this is a big missing piece in the API and am glad we're
looking at this.

I don't see why the SearchDone can't call a CloseSearch in case of an
error. However, if these are the only 2 options, then I am in favour
of a SearchFailed because it seems to be cleaner (error path is kept
independent of the regular path).

A few thoughts:

a) SearchFailed might be bad nomenclature. For example, setting an
invalid property should raise an error, but not cause the search to
fail.

b) There can also be errors at the Session level. How do we handle
those? For example, I think using a closed search handle should be a
Session error rather than a Search error. Maybe we can have 2 signals
"SessionError" and "SearchError" to handle these?

Cheers, (and sorry for the duplicate copy, Mikkel)
-- 
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com