[Xesam] Need paged search mode for xesam

[Philip Van Hoof]

On Tue, 2008-05-06 at 22:08 +0530, Arun Raghavan wrote:
> On Tue, May 6, 2008 at 9:30 PM, Philip Van Hoof <spam at pvanhoof.be> wrote:
> <snip>
> >  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.
> 
> Could you please elaborate what functionality could be moved from the
> server to the client? Without the state, how would live searches be
> implemented?

Just throw all added hits, all removed hits and all modified hits to all
clients and let them sort it out themselves (state at the client).

Important note, though ...

I'm NOT saying I disagree with the usefulness of a statefull service,

I am saying that a statefull service invites to have features like
server-side paging (or cursors, or whatever fancy name you think is
elite today): because keeping state implies certain complexity.

For example one person raised the argument of grep based searchers:

Those will have to somehow keep track of changes too, so they need to
store state like the actual returned results per client, or inotify
subscriptions on all found files, or whatever.

If you don't, you can't know whether or not you must throw a HitsAdded,
HitsRemoved and HitsModified to your client. If you don't do that, you
are not doing live-searches. This means you end up NOT doing what you
made your service statefull for in the first place.

So statefullness implies having this complexity. Once at this level of
complexity, adding paging (or cursors) ain't difficult at all anymore:

Just return a slice out of your state in stead of the whole thing.


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be