[Xesam] SearchDone vs server side errors
Mikkel Kamstrup Erlandsen
mikkel.kamstrup at gmail.com
Wed Jul 16 15:00:29 PDT 2008
2008/6/30 Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> 2008/6/24 Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
>> 2008/4/22 Jos van den Oever <jvdoever at gmail.com>:
>>> 2008/4/22, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
>>>> 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.
>>> To clarify further: we are talking about an error _signal_ not a return value.
>>> And according to the spec, SeachDone is always emitted. So it would be
>>> only natural to have indicate _how_ the searche ended: success or
>>> failure. So I opt for option 2. But option 1) is nice too. Important
>>> is that the asynchronous failure notification is in the spec.
>> Consider this thread bumped. It is in our list of blockers I recently
>> posted and we need a clear decision.
>> I just realized that Jos only send the above to me. So please read it
>> before going on. (@Jos: Hope it is OK I forward it here).
>> Like Jos I am in favor of option 2. Please see thread root for the
>> problem statement:
> While walking the dog I had another crackpot idea. If we are going to
> break SearchDone, we might as well do it completely :-)
> My thought was that the following (likely) scenario is racy:
> --- wait for SearchDone
> In between the emission of SearchDone and GetHitCount() more hits
> might have been added and GetHitCount will return too many hits. So
> while we're at it we could add another parameter to the proposed
> SearchDone solution, so it looks like:
> SearchDone (s: search_handle, u: hit_count, i: exit_code, s: message)
> Ie. include the hit count at the instant of the SearchDone emission as
> compared to the original proposal. Anyways, maybe this is nitpicking.
You can now find this as item 2 on http://xesam.org/main/XesamUpdates
Please complain if you have problems with it :-)
More information about the Xesam