(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 <[email protected]> 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? >
