[Xesam] SearchDone vs server side errors

[Mikkel Kamstrup Erlandsen]

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.
>>
>> Cheers,
>> Jos
>
> 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:
> http://lists.freedesktop.org/archives/xesam/2008-April/000115.html

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:

StartSearch(s)
--- wait for SearchDone
GetHitCount(s)

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.

Cheers,
Mikkel