[Xesam] Need paged search mode for xesam

[Mikkel Kamstrup Erlandsen]

2008/5/6 Philip Van Hoof <spam at pvanhoof.be>:

>
> On Tue, 2008-05-06 at 11:28 -0400, Jamie McCracken wrote:
>
> >
> > we dont want to implement on client !
> >
> > this is server based paging
>
> I kinda agree with Jamie here.
>
> I don't really see the point in having state stored about sessions and
> searches on the service, if not for paging purposes.
>
> Maybe indeed for HitsAdded, HitsRemoved and HitsModified. But to have
> full session and search infrastructure just for that ... ?
>
> My opinion is that if paging is to be done entirely by the client, then
> HitsAdded, HitsRemoved and HitsModified should have to be done by the
> client too.
>
> Then you could have a stateless service, and that would have made a lot
> of sense indeed (far less complex service implementations).
>
> Having to store state of sessions but not getting paging from the
> service, sounds a bit like adding a lot for relatively few gain.
>

Indeed the very first drafts of the API where stateless. After a lengthy
debate everyone agreed on a stateful model (search the xdg archives on FDO).
The wiki pages on FDO can also give you the prehistoric drafts if you are
interested.

If I recall correctly some of the reasons where:

 * Without state the query the query xml string will basically have to be
the search handle, meaning that the server would have to recognize it on
each request (parse it or md5 or whatever). This is a buggy behavior though
since the same search is not guaranteed to return the same results at any
later point in time

 * State allows for a *lot* of optimizations on the server. For example
retrieving fields from a Lucene index is not always fast - that depends on
how your index is laid out, prefetching field data according to hit.fields
can possibly pay off. For index-less backends state is even more essential.

 * Knowing whether or not to monitor the result set is also very valuable
(search.live). Find-as-you-type front ends can spawn many searches you know
- likewise for user context searches (eg. dashbord)

There are lots of other reasons, but I really do not want to go into that
discussion. It is at the very core of the spec and it is not really
constructive to start picking on that at this point in time.

We can revisit it if we ever want to make API breaking changes (ie Xesam
Search 2.0).

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xesam/attachments/20080506/dfb81dc0/attachment.htm