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 >
