[aur-dev] pkgbase queries via RPC interface

[Lukas Fleischer]

On Sat, 16 Aug 2014 at 05:25:12, Xyne wrote:
> [...]
> That works for me. In that case, the method should accept a list of fields to
> search (pkgname, pkgbase, pkgdesc, maintainer, deps, url?, etc.). There should
> be a way to search for exact matches (e.g. to retrieve data about a specific
> package or package base). That could be done either with regexes (too much
> server overhead?) or an extra parameter that forces a perfect match.
> 
> The returned objects should include a "type" field to specify what kind of
> object they are ("package", "package base").
> 
> A filter to reduce the returned fields may be useful in some cases but it's
> easy enough to filter on the client-side. I suppose it's a matter of cpu vs
> bandwidth for the server.
> [...]
> I'm not sure what the best way to build in boolean logic would be ("and", "or",
> "xor"?, etc.) or if it is even something that you would want to implement.
> Maybe with a custom "advanced" parameter that accepts a string that the server
> can parse directly (using some existing syntax?).
> 
> 
> 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.

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.