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

[Fabrice Colin]

On 11/24/06, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com> wrote:
> 2006/11/23, Fabrice Colin <fabrice.colin at gmail.com>:
> > What Magnus suggests may be useful for document 'sources' or 'groups' (for
> > lack of a better name), eg "Documents", "Applications", "Contacts",
> > "Conversations" etc... -as offered by some existing personal search
> systems-
> > which may or may not map to individual indexes (that mapping being
> irrelevant).
>
> That was exactly what I meant to cover with the "group" switch. Fx. the
> query "fabrice group:contacts" would return you. Searching without a
> specified group would return matches from all groups. Perhaps the wiki is a
> bit unclear here...
>
The Wiki is clear enough. It's just that it may be useful to provide
the consumer
application with a list of supported groups... unless we dictate which
groups should
be supported by all engines.

> > Well, AFAIK, dbus allows complex structures like arrays or dictionaries.
>
> Yeah, but that really only accounts as collections of simple data types in
> my book. What I meant was just that you can't have Query object, like fx
> Lucene does, and pass that over the wire. Not in a desktop neutral way at
> least - or please correct me if I'm wrong! :-)
>
Hmmm it depends on. As the dbus specification says, you can have "array of
array of array of ... struct of struct of struct of ...", which is
probably flexible enough
to pass all the data held by a Query object.

> Right you are. I was a bit wasted last night when I  answered Magnus (sorry)
> - I just thought her deserved an answer sooner rather than later.
>
No worries ;-)

> The question is then if this info should be stored in  the manager daemon or
> the search engine. As I consider it more or less a design goal that the
> daemon (or lib or what ever we end up with), should be expendable, I don't
> think such info should lie with the managing object. Also if this info would
> reside with the managing object that would also mean each query should go
> through the managing interface, and I don't think I'm totally hooked on that
> idea.
>
> To avoid code duplication we could develop a small lib or other dbus service
> to *optionally* handle these issues. I'm reluctant to impose any dependency
> on the implementing engines.
>
We could have an optional prefix (a switch-type, according to the
draft) for language,
so that this information is carried by the query string.
A braindead example : if the engine supports "language", "the moose
language:english"
is interpreted as a query for "moose", while "the moose
language:swedish" is a query
for moose tea :-)

Fabrice