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

[Kevin Krammer]

On Sunday 26 November 2006 18:17, Jean-Francois Dockes wrote:
> Jos van den Oever writes:
>  > 2006/11/26, Jean-Francois Dockes <jean-francois.dockes at wanadoo.fr>:
>  > >  1- A need for trivial enabling of text search in any (non-search)
>  > >     application, with minimal fuss, (better described by Fabrice in
>  > > the quoted message).
>  >
>  > For this, we also need a way to search in documents that have not been
>  > indexed. Indexes can take up a lot of space and the user might not
>  > want to have an index of all her data, but still want to search that
>  > data now and then.
>  > Since searching in this way is a lot slower, there would need to be a
>  > more asynchroneous method of reporting the search results.
>
> I'm not a d-bus expert, but at least with the qt4 bindings, it seems that
> you have a choice of waiting for the reply to a d-bus message, or be called
> later when it arrives. There doesn't seem to be anything inherently
> synchronous in d-bus, so I would imagine that other bindings or adaptors
> have similar capabilities.

Technically correct, this is a feature of the low-level D-Bus library.

However this is a different use case.

The asynchronous D-Bus call is for getting _the_ result later.

The use case discussed here is slightly different (unless I am 
misunderstanding) it is about returning _some_ results later.

Example: a user searches through a lot of emails. The program should be able 
to display results as soon as possible. At this point the results do not need 
to be complete, matches can trickle in when found.

An asynchronous call would still have to wait for all results, i.e. a 
completed query. The user would have to wait for the slowest match.

An option would be to have the initial query call return a query identifier 
instead of results and results would be transported by D-Bus signals using 
this identifier as a reference.

A bonus would be to have the possibility of cancelling a query using this 
identifier. The user might already have found what they were looking for and 
cancel the search operation in their program. An ongoing searching operation 
would not be a problem for the program (it can just ignore any further 
results), but it could be hard to explain to a user why their harddisk keeps 
accessing files like mad.

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/20061126/3abe8a71/attachment.pgp