[XESAM] API simplification?

[Jos van den Oever]

2007/7/16, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> 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
>
> * Query Language:
> I suggest we remove the "type" attributeon the query element. You can just
> specify the Category- or StoredAs fields in you selectors.

I completely agree on all suggestions.
One more suggestion: the minimal interval between result signals
should be sane or settable.

On the topic of remembering the hits.
In ideal world, the server could be clever and get the right file from
the hit number. In reality, this is quite hard. Atm the server should
keep a vector with uris internally. I think we should allow the server
to have a sane maximum of hits that are retrievable. E.b. CountHits
might return 1 million, but you would only be able to retrieve the
first 100k.

This is actually a scalability issue. We should allow the search to
modify the vector when the hit has not yet been retrieved and only
guarantee reproducibility for hits that were retrieved already. In
combination with a maximum history size this would handle most
performance problems.

Cheers,
Jos