[Xesam] Need paged search mode for xesam

[Mikkel Kamstrup Erlandsen]

2008/5/7 Jamie McCracken <jamie.mccrack at googlemail.com>:

>
> On Wed, 2008-05-07 at 20:44 +0200, Mikkel Kamstrup Erlandsen wrote:
> > 2008/5/7 Jamie McCracken <jamie.mccrack at googlemail.com>:
> >
> >         On Wed, 2008-05-07 at 16:29 +0200, Jos van den Oever wrote:
> >         > 2008/5/7 Jamie McCracken <jamie.mccrack at googlemail.com>:
> >         > >  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xesam/attachments/20080507/a9ba9b6f/attachment.html