[Xesam] SearchDone vs server side errors

[Mikkel Kamstrup Erlandsen]

On 19/04/2008, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com> wrote:
>
> It was noted on IRC that the search engine has no way of telling the
> client "hey I screwed up" after StartSearch(s) has been invoked. The reasons
> for this could be many - OOM, non-fatal bug, full moon, etc.
>
> Currently the only real solution is to emit SearchDone and let the client
> wonder why it only received 0 hits.
>
> There are two alternatives :
>
> 1) Introduce a new signal SearchFailed(s: search_handle, i: error_code, s:
> message). This will be the  API compatible solution
>
> 2) Add a new value to the SearchDone signal, changing signature to
> SearchDone (s: search_handle, i: exit_code, s: message). This will break API
> however
>
>
> I hate 2) because it (doh) it breaks API. I love 2) because it will fit
> much better in to my control flow logic. I am more or less indifferent on 1)
> - it is not very clean IMHO, but it is API stable. Status quo could be
> acceptable to me, but I think it could be a good idea to make better room
> for handling of bugs. After all Xesam is an all new technology we are pusing
> in.
>
> 2 gets my vote. I am very much willing to reconsider if people are
> massively annoyed by this (small) API change.



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

So from +1 on 2) I have swung my mood to "indecisive". If I don't get
feedback on this we will go for the API stable solution (ie adding
SearchFailed).

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