2008/5/7 Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>>:<br><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">2008/5/7 Jos van den Oever <<a href="mailto:jvdoever@gmail.com" target="_blank">jvdoever@gmail.com</a>>:<br></div><div class="gmail_quote"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>2008/5/7 Philip Van Hoof <<a href="mailto:spam@pvanhoof.be" target="_blank">spam@pvanhoof.be</a>>:<br>
</div><div>> Calling a discussed solution that we intent to move to spec as soon as<br>
> possible proprietary because somebody does not want to utilise an<br>
> extremely loosely specified hack that only works by accident*, is rather<br>
> sad.<br>
><br>
> I have better things to do with my time, really.<br>
<br>
</div>If someone says: i'll add such a function regardless of the spec, then<br>
yes, that's proprietary.<br>
As Mikkel has replied, the proposed solution is absolutely no hack.<br>
The documentation needs to be improved a bit, but that's it.<br>
<br>
I care just as much about the spec as anyone here and I'd hate to see<br>
it being fragmented in a 1.1 and 2.0. If there is no pressing need to<br>
change what we have, shouldn't. Perfection is the enemy of success and<br>
this is even more true for trying to write specs. Even when the spec<br>
writers love each other as much as we do. :-P</blockquote></div><div><br>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.<br>
<br>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).</div>
</div></blockquote><div><br><br>Back from vacation.<br><br>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.<br>
<br>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:<br><br> GetPagedHits (in s search, in au pages, out aav hit_data)<br></div>
</div><br>Because you know which pages you retrieve you can map the hits in hit_data to the correct hit ids.<br><br>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<br>
<br> GetPagedHits (s, [current_page+1, current_page+2, last_page])<br><br>This way you can anticipate the user sccrolling to the bottom and have a very responsive ui. Might be total over engeneering though.<br><br><br>On another note - can someone explain to me why DBus is slow on the Nokia devices? Is it an ARM thing?<br>
<br>Cheers,<br>Mikkel<br>