2008/5/6 Philip Van Hoof <<a href="mailto:spam@pvanhoof.be">spam@pvanhoof.be</a>>: <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d"> On Tue, 2008-05-06 at 11:28 -0400, Jamie McCracken wrote: > > we dont want to implement on client ! > > this is server based paging </div>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. </blockquote><div> 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 </div></div>