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

[Jos van den Oever]

2006/11/26, Kevin Krammer <kevin.krammer at gmx.at>:
> 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.

Exactly. And having live queries is similar to this.

I'm not the best person to propose an asynchronous language because
Strigi has only synchronous queries at the moment. If there's a good
API, i might change that according to that API.

Cheers,
Jos