On 16/08/14 15:52, Lukas Fleischer wrote:
On Sat, 16 Aug 2014 at 05:25:12, Xyne wrote:
I'm just kicking around some ideas for the sake of discussion.
I'd rather not overcomplicate things. Having a "by" parameter, the possibility to pass one or multiple (fixed) strings and an option to enable exact matching is what I was thinking of. I do not think that combining search types gives a substantial benefit.
I think that this is about right. The biggest weakness with the current search interface is not being able to query anything other than the name and description - so something like a "by" parameter would be very welcome. The only other thing that can't be fully implemented on the client side is negation. It's possible to exclude terms if they are combined with at least one other positive term. For instance, to search for "foo" AND NOT "bar", you can first search for "foo" and then do some post-filtering on the client side to exclude "bar". But what if you wanted to search for *all* packages that do not contain "bar"? This is currently impossible, because you'd need to pull the entire package list before it could be filtered on the client-side. So I would like to suggest adding something like an "narg" parameter to complement the "arg" parameter, to allow for the possibility of a list of terms to be excluded from the search results.
If we really need to support very powerful queries, it might be better to reconsider another idea I had earlier: Replace the RPC interface with a static database. Basically, the result of an RPC query that matches every single package is computed every hour (or so) and stored in a flat file which can be downloaded, similar to pacman databases. AUR helpers can download that file and do whatever they want. Note that this file will probably be quite large, though (roughly 5-10MiB when compressed, did not check with the latest set of packages). I am not sure whether this is the best thing to do, since, unlike in the case of the official repositories, users are usually only interested in a tiny amount of AUR packages.
I think the most significant difference between the the official repos and the AUR is volatility. The AUR is subject to far greater and more frequent change, and, unlike the official repos, those changes are far less co-ordinated (to put it mildly). So for the AUR, it is perhaps more important to have the most up-to-date information available, than it is to have to greater control over the entire database. Having said that, I don't think having a downloadable static database is a bad idea in itself - I'm sure many people who maintain AUR helpers would like to have it there as an option. But I think it would be a mistake to have it replace the RPC interface altogether.