On Wed, 13 Aug 2014 at 06:56:00, Xyne wrote:
Hi,
The RPC search, info and multiinfo methods return no data when the pkgbase is passed as the argument.
I would like to discuss the following ideas:
A) Return all of the packages in the pkgbase for search, info and multiinfo queries. For search and multiinfo this would be natural. For info it would be left to the client to detect that the result is an array instead of an object and thus infer that the result is from a pkgbase (or simply add that data to a new field in the result object). With the advent of the query version parameter this should not be an issue for backwards compatibility.
I don't quite understand the idea. What is the argument that is passed to the RPC? * A package name? If so, I personally think it is very counterintuitive to return all "related" packages as well. Also, we are going to waste bandwidth by often returning information the user is not interested in. * A package base name? Does that mean we will no longer be able to search for packages? * Both? What happens if there is a package base and a package with the same name (and the package doesn't belong to that package base)?
B) Add a parameter to query pkgbase data (e.g. object=pkgbase) and return a JSON object with pkgbase-specific data (everything that still applies from regular package data, plus an array of the included packages). Given that there are AUR pages for pkgbases, it would be consistent to provide that data via the RPC interface.
This sounds better to me.
I believe this would be very useful. What do you think? Would it be difficult?
I like this idea. Should not be too hard to implement. Maybe we should make the whole thing more flexible by replacing everything with a single search method (instead of search, info and multiinfo) with different search modes (packages and package bases), a filter to specify the fields on is interested in and different query types (by name, by name and description).
Regards, Xyne