2008/5/7 Jamie McCracken <<a href="mailto:jamie.mccrack@googlemail.com">jamie.mccrack@googlemail.com</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 Wed, 2008-05-07 at 20:44 +0200, Mikkel Kamstrup Erlandsen wrote: > 2008/5/7 Jamie McCracken <<a href="mailto:jamie.mccrack@googlemail.com">jamie.mccrack@googlemail.com</a>>: > >         On Wed, 2008-05-07 at 16:29 +0200, Jos van den Oever wrote: >         > 2008/5/7 Jamie McCracken <<a href="mailto:jamie.mccrack@googlemail.com">jamie.mccrack@googlemail.com</a>>: >         > >  we need ranges in order to search efficiently - having >         potentially >         > >  random hit IDs passe to that function means we cannot >         optimise (no way >         > >  to tell in advance if its a range) >         > > >         > >  Its so bad that we will add an extension GetPagedHits >         ourselves if no >         > >  one else wants it! >         > >         > You're seeing ghosts. It's trivial and very quick to check >         if a range >         > of numbers is sequential. >         > If it's sequential, you can use your optimized range >         function, if not, >         > get the hits one by one. For the later you need a function >         anyway. >         > > > > Jamie?  Can you comment on Jos' answer? If you implement paged hit > retrieval anyway, it would be a very cheap optimization to check if > hit_ids are sequential in GetHitData and then take the optimized path. </div>I can see it working but it is a hack - and we all agree on that If you dont wanna get bugged by devs wanting to know how to do paged searches all the time then i would suggest adding the API pronto :) Bear in mind dbus is slow on nokia and the added type checking all adds up as well as checking if the array is sequential.</blockquote><div> I didn't know that. That is of course an important factor. I have anticipated dbus not being a greased lightning, but not exactly slow.  </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Nokia devs are doing a lot of work profiling tracker to squeeze every ounce of performance out of it (if you had not noticed, latest version is pretty much the fastest indexer as latest linux source is indexed in under 4 mins) for their sake, Im adding GetPagedHits for their usage and maybe TST only so it should not subvert your spec  nor break other xesam apps <div class="Ih2E3d"> > > If it is not enough to simply change the documentation of GetHitData > to imply that it is more advanced way to retrieve hits (and not mainly > a tool to use on HitsModified), can you then be more specific about > your needs (for the method)? I am thinking: > >  * A use case - No app I know of will require the API you describe. > Not even the native Tracker search tool (it can only scroll pages > sequentially). Anywhere libbeagle is usable, so is Xesam, but with a > more advanced interface. </div>well we will want to do variable paging so it gets stuff as you scroll - it can be random too as you can move the scroll bar anywhere so yeah TST would like it</blockquote><div> If someone writes a GtktreeModel paging in hits as you scroll (via proxy objects to get row heights and scroll bar size right), I'd love a ping. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> >  *  Should it take an array of fields to retrieve, or use the <div class="Ih2E3d">> hit.fields property like GetHits? </div>I think we would need: GetPagedHits GetPagedHitData to cover all use cases </blockquote><div> If there is more than one method needed for paging nirvana it begins to make sense to add a org.freedesktop.xesam.PagedSear<div>ch interface to the spec. This can go in 1.1 (and if we can mature it fast enough it should not be a problem for Nokia to depend upon it before 1.1 is out). </div> Cheers, Mikkel </div></div>