simple search api (was Re: mimetype standardisation by testsets)

[Kevin Krammer]

On Monday 27 November 2006 12:08, Mikkel Kamstrup Erlandsen wrote:

I am not a searching or indexing expert, merely wanted to input some 
information regarding D-Bus sync/async calls :)

> I think you raise a really good question Kevin. Let me  first introduce
> some  terminology to ease the communication.
>
> Page Query: All results for a given query is returned in one chunk. This
> call is still *async* since it is over dbus. This is how it is sugegstedin
> on the WasabiDraft wiki page.
>
> Async Query: Query results trickle in as the search engine picks them up.
> Ie all query results are not returned in one batch.

I'd rather call it "Full" and "Partial" Query or Query with "Full" 
or "Partial" delivery.

> In the page query the client can simulate an async query by requesting
> several blocking queries with the same query string, but different
> page-ranges. This gives a small problem with page ordering, but nothing
> that the client app could not work around. The big benefit for page queries
> is that server side sorting (score, relevance, date, whatever) is a
> no-brainer for the client. Just append the "sort:<sorttype>" switch to the
> query string.

How long does a search service have to cache such a query - result 
combination?
Or is searching so fast, that the same query can be re-done on every call?

> In the async query you have a sorting problem. The client cannot sort the
> hits, unless each returned URI also has metadata associated with it (it
> looks this stuff up with another dbus call). I see a huge benefit in
> allowing the results to trickle in (and allows for canceling queries as
> Kevin points out). The async query is also much more suitable for live
> queries (in the sense of updating the query when the on-disk files change -
> or are deleted/created).

Would it be possible to associate a sorting key with each match?
If so it could be part of the returned data, i.e. the result being an array of 
tuples of URI and key.

> So what do I think? I see 2 options:
>
> 1) Change the Query method name to PageQuery and add another AsyncQuery
> with a signature and behavior we need to think a bit about.
>
> 2) Don't change the org.freedesktop.search.simple interface, but create
> another interface generally aimed at live queries - or maybe include this
> in the "advanced" search interface when we get to defining that.

A more advanced interface could be based on query objects, i.e. the client 
requests a remote peer object for a specific query and the service creates an 
handler object and returns the object path.

The client can then call this object's methods and listen to this object's 
signals, without needing to reference it with the query string at each call 
or on each signal. The object path will be the reference

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20061127/897f81fd/attachment.pgp