[XESAM] API simplification?

[Mikkel Kamstrup Erlandsen]

2007/7/17, Arun Raghavan <arunisgod at gmail.com>:
>
> Hello
>
> On 7/16/07, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com> wrote:
> > Hi again,
> >
> > I have a few suggestions for updates to the xesam search spec.
> >
> > * API:
> > Remove the session properties search.blocking and search.live. These
> seemed
> > to cause more confusion than I anticipated. These can be emulated in the
> > client side lib as far as my scribblings can tell. Anoter solution might
> > just be better documentation of course...
> >
> > Some of you now have actual experience with these, what is your feel?
> >
> > The reason for having these properties in the first place was to allow
> > easier usage of the dbus interface directly - ie not via a client lib.
> >
> > What this would mean for the api methods:
> >  * GetHits should always block until the requested number of hits has
> been
> > found or the entire index has been searched (in which case the
> SearchDone
> > signal will be emitted too).
> >  * CountHits should always block until the entire index has been
> searched
> >  * No other methods should block
> <snip>
>
> I have no experience with client design, but here's my suggestion:
>
> "search.live" should remain, but "search.blocking"
> should probably be dropped. By definition, a non-live search will
> cause GetHits() and CountHits() to block till the search is finished.


By the current standard search.live does not determine this behavior. That
is the matter of search.blocking. If search.blocking is false these methods
should return immediately with current avail hits or current found number of
hits (which will only be final when the entire index has been searched). Or
are you talking about the new suggestion?

A live search will never block -- both these calls will return with
> what hits are available. This seems to be a reasonably intuitive model
> to me.


Did you mean to post to the list? Please post there if you wanted to, I'll
put a reply there too then.

The reason for just letting all calls block is that dbus has a build in
mechanism for doing async calls (via a callback when the method returns) -
thus if we always stick with dbus (and don't want to do a
xesam-over-unix-sockets spec in the future) we can safely say that GetHits
and CountHits always block.

Another important matter might be whether or not to keep the hit set around
on the server? Atleast some clients such as deskbar has no need to re-read
hits or fetch additional metadata via GetHitData. We could specify that if
search.live == false the server is free to drop the hits as soon as they are
read with GetHits.

This last idea would imply that the GetHitData method only makes sense if
search.live == true. If not it should probably return an empty set (dbus has
no NULL) or throw an error.

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070717/587c9dc4/attachment.html