[Xesam] Need paged search mode for xesam

[Mikkel Kamstrup Erlandsen]

2008/5/7 Jos van den Oever <jvdoever at gmail.com>:

> 2008/5/6 Jamie McCracken <jamie.mccrack at googlemail.com>:
> >  hit_ids are not sequential!
>
> They are sequential. From the spec:
>  "The hit_ids argument is an array of serial numbers as per hit
> entries returned by GetHits."
>

Uhm, that was not the intention :-) The hit_ids argument is an arbitrary
array of hit ids, fx, [1, 7, 28]. It is meant to make it convenient to react
to HitsModified or the user selecting a collection of elements in a ui.

I am open for making it sequential access though (even though this would be
an API break). This would possibly result in a lot of dbus traffic if I move
a dir with the Linux kernel source and the server emits HitsModified for all
the files (and my app would need to call GetHitData on all affected hits -
which are unlikely to have sequential ids).


>
> The current spec requires that the server keep a list of all uris
> mapped to hit ids somehow. Of you know the index will not change you
> can rerun the query.
>
> There is no need to fetch  a single uri via GetHits. The HitsAdded
> signal tells you how many hits there. You do not have to use GetHits
> at all. If you use GetHitData exclusively for getting the data, you
> basically are paging.
>
> So the current spec is fine for sequential access _and_ paging.


I would think so too - no matter what the conclusion on the misunderstanding
above is.

I am still very open for discussions, but I have yet to see a (realistic)
use case where the current spec would fail. I think we need a good use case
and detailed spec of the suggested new API (what it does in error
conditions, is it correlated with GetHits sequential access, does it use
hit.fields or take requested fields as params - like GetHitdata, etc).


Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xesam/attachments/20080507/30a71718/attachment.html