[Xesam] SearchDone vs server side errors

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Tue Apr 22 12:13:58 PDT 2008


2008/4/22 Arun Raghavan <arunisgod at gmail.com>:

> 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.
>

According to the spec, SetProperty (ses, prop, val) should return a dbus
error if ses is closed or invalid, or if prop is not a valid property, so
this should be covered.


>
> 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?
>

That is not a problem, the dbus methods can return dbus errors (read: throw
exceptions). The Managed C# dbus bindings will probably marshal an exception
to a dbus error (python-dbus does this at least). It is speced out when the
methods should throw exceptions

The problem comes after StartSearch is invoked - here you will just sit idle
waiting for HitsAdded or SearchDone if the search dies before the server can
emit anything.

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xesam/attachments/20080422/6ee11d93/attachment.htm 


More information about the Xesam mailing list