On 2014-08-16 16:52 +0200 Lukas Fleischer wrote: >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. > >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.
The advantage of real-time results is that they can be used to confirm uploads and other operations. Making a compressed database available may be useful in its own right but I would not want to see it replace the current system. Given that the current search already searches by both name and description, would a single "by" parameter be able to at least accept a character-delimited list to search multiple fields (e.g. pkgname:pkgbase:pkgdesc)? If not, what about accepting multiple "by"s for a combined OR search?
