[Xesam] Need paged search mode for xesam

[Mikkel Kamstrup Erlandsen]

2008/5/7 Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:

> 2008/5/7 Jos van den Oever <jvdoever at gmail.com>:
>
> > 2008/5/7 Philip Van Hoof <spam at pvanhoof.be>:
> > >  Calling a discussed solution that we intent to move to spec as soon
> > as
> > >  possible proprietary because somebody does not want to utilise an
> > >  extremely loosely specified hack that only works by accident*, is
> > rather
> > >  sad.
> > >
> > >  I have better things to do with my time, really.
> >
> > If someone says: i'll add such a function regardless of the spec, then
> > yes, that's proprietary.
> > As Mikkel has replied, the proposed solution is absolutely no hack.
> > The documentation needs to be improved a bit, but that's it.
> >
> > I care just as much about the spec as anyone here and I'd hate to see
> > it being fragmented in a 1.1 and 2.0. If there is no pressing need to
> > change what we have, shouldn't. Perfection is the enemy of success and
> > this is even more true for trying to write specs. Even when the spec
> > writers love each other as much as we do. :-P
>
>
> I will be gone until Monday or Tuesday. Feel free to continue the
> flamefest while I am gone, but I think it would be a good idea to ponder
> this a few days befire we flame on anyways.
>
> Just a thought before I sign off for now - if the idea is to do really
> really optimized paging then GetPagedHits (s, offset, count) might not be
> what we want. By using a search.pagesize session property the call could be
> reduced to GetHitPage (s, page_num) and the server would have a chance to
> pre-prepare the pages for maximum efficiency. Other small tweaks might be
> possible. This is Jamie's original 3).
>


Back from vacation.

I've been thinking quite a bit about this. If you are going to implement
this no matter what it makes good sense to wait until you are ready and then
I'll do an actual performance test of the two APIs and compare the results.
If you are right then I can definitely see us moving it into the spec. If
you are not right you still haven't wasted a single second on the
implementation of your paged search because it can be moved into GetHitData
as Jos described.

Specifically on the API, the most optimized API I can come up with is to use
a session prop for page size and then request *batches* of pages:

  GetPagedHits (in s search, in au pages, out aav hit_data)

Because you know which pages you retrieve you can map the hits in hit_data
to the correct hit ids.

This can be used in wicked ways. Fx if you want to retrieve hits as the user
scroll. If the user initiates a very fast scroll downwards you retrieve the
two next pages *and* the very last page. Ie

  GetPagedHits (s, [current_page+1, current_page+2, last_page])

This way you can anticipate the user sccrolling to the bottom and have a
very responsive ui. Might be total over engeneering though.


On another note - can someone explain to me why DBus is slow on the Nokia
devices? Is it an ARM thing?

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xesam/attachments/20080513/43ddcb4e/attachment.html