(Aura author here) I personally use real-time results to confirm uploads all the time. I wouldn't be in favour of a DB replacing the RPC. That said, every once and a while I have feature requests from users along the lines of "Well if you had a local AUR db then feature X would be trivial." On 16 August 2014 11:24, Xyne <xyne@archlinux.ca> wrote:
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?