2008/5/7 Jamie McCracken <[EMAIL PROTECTED]>: > > On Wed, 2008-05-07 at 20:44 +0200, Mikkel Kamstrup Erlandsen wrote: > > 2008/5/7 Jamie McCracken <[EMAIL PROTECTED]>: > > > > On Wed, 2008-05-07 at 16:29 +0200, Jos van den Oever wrote: > > > 2008/5/7 Jamie McCracken <[EMAIL PROTECTED]>: > > > > 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. > > 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.
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. > 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 > > > > > > 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. > > 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 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. > * Should it take an array of fields to retrieve, or use the > > hit.fields property like GetHits? > > I think we would need: > > GetPagedHits > > GetPagedHitData > > to cover all use cases > If there is more than one method needed for paging nirvana it begins to make sense to add a org.freedesktop.xesam.PagedSearch 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). Cheers, Mikkel
_______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
