[packagekit] RFC: standardising on search terms

[Richard Hughes]

On Thu, 2008-12-25 at 10:13 +0100, Sebastian Heinlein wrote:
> We should support the basic operations most people use when searching in
> google: multiple key words. But I don't see a reason not to silently
> support regular expressions or boolean operations.

I don't think silently supporting a standard is a good way to work -- it
breaks validation and could be used in an exploit in the future. Any
search standard has to be concrete.

> I even have got a bug report about not working multiple keywords.

Yes, me too.

> Furthermore personally I regularly search for more than one term and
> expect from every search machine (in the web or in programs) to support
> this naturally.

Both or either? For instance, if I search for "gnome power" do I expect
results that match gnome AND power, or all results that match gnome OR
power? I think most people expect AND, right?

Should the client side make this policy decision? For instance, mapping
"gnome power manager" into "gnome AND power AND manager"? This seems
like the best solution where we are allowing advanced users to use
"power NOT gnome" and let casual users just type search words.

What about supporting: AND, OR, NOT and no nesting (brackets)?

> Why add this to the client side? Clients should be as tiny as possible.
> If you don't want to have this in the backends you should add this to
> the packagekit daemon. But this could be a slow down: running the search
> over the cache several times and merging the results.

Yes, I don't really want the client or server filtering out duplicate
entries, this is the job of the backend. I agree this has to be done in
the backend.

Richard.