2008/6/24 Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]>: > 2008/4/22 Jos van den Oever <[EMAIL PROTECTED]>: >> 2008/4/22, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]>: >>> 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 _______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
