You are not logged in.
Before I submit a feature request, I wanted to check if I've mis(sed|understood) something. The json page (is that the right terminology?) currently recognizes two methods: search and info. Each method accepts a single argument, so it seems that if I need to get info for several packages, I need to submit multiple requests.
It would make more sense to be able to submit a single request with an array of packages to avoid multiple calls. This would be useful in apps such as yaourt and others that interact with the AUR and normally need to retrieve info for several packages. Am I correct in thinking that this is currently not possible? If I am, I'll submit a feature request.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Seems like somebody has sent a patch to aur-dev today for getting info of all packages in a single shot.. have a look at aur-dev mailing list...
Offline
Nice... now we just need one for ABS.
*cough* ![]()
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Nice... now we just need one for ABS.
File a feature request.
Offline
It would make more sense to be able to submit a single request with an array of packages to avoid multiple calls. This would be useful in apps such as yaourt and others that interact with the AUR and normally need to retrieve info for several packages. Am I correct in thinking that this is currently not possible? If I am, I'll submit a feature request.
* If you submit an array of packages, how do you handle/return failures?
** If one package out of 30 is not found, what do you return?
** If 29 packages out of 30 are not found, what do you return?
** How do you return failure/status codes without breaking existing clients?
*** Or do you just break existing clients and tell everyone to upgrade?
* How would you handle the sql query?
** Just glue together a bunch of where like clauses? What if someone submit 50 packages. Will it overflow the sql query length? (i think the max mysql query length is 1048574 bytes)
** Fire individual queries for each one and glue together the results? (better option, but there is little benefit over multiple requests here, from the DB perspective)
The decision to originally only allow one package in a query request was done _on purpose_ after some careful thought.
So no, there is no way to currently request more than one package with the info or search, short of having search return multiple matches based on a string partial.
Sure it would be possible to change the code to make it happen, but to do it _right_, it wouldn't be trivial.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
* If you submit an array of packages, how do you handle/return failures?
** If one package out of 30 is not found, what do you return?
** If 29 packages out of 30 are not found, what do you return?
** How do you return failure/status codes without breaking existing clients?
*** Or do you just break existing clients and tell everyone to upgrade?
I would concatenate the current output. It already returns a status code for each request in the form of "type":"info" or "type":"search" on success and "type":"error" on failure. The default behavior would not require any change. If you're really worried about someone having written a "dumb" parser that simply slurps beyond the curly brackets, then maybe it would be possible to have a second interface, although holding back progress to accommodate lazy programming is bad in general and inappropriate in Arch.
* How would you handle the sql query?
** Just glue together a bunch of where like clauses? What if someone submit 50 packages. Will it overflow the sql query length? (i think the max mysql query length is 1048574 bytes)
** Fire individual queries for each one and glue together the results? (better option, but there is little benefit over multiple requests here, from the DB perspective)
Yeah, I would run separate queries. The DB doesn't benefit from it, but it doesn't lose out either (read: it's exactly the same thing as now, thus neutral). The benefit comes from reduced bandwidth usage both serverside and clientside, plus a faster response time overall due to far less connections. Actually, thinking about it now, the database might even see a slight benefit as you would reduce the number of times you need to create a connection to the database (once per operation, instead of once per query).
Sure it would be possible to change the code to make it happen, but to do it _right_, it wouldn't be trivial.
I believe that all this would need is a way to split the arguments into an array, stick the lookup in a foreach loop, then concatenate the output.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Xyne wrote:Nice... now we just need one for ABS.
File a feature request.
Done: http://bugs.archlinux.org/task/13026
(feel free to move it to the right category... I accidentally submitted it before setting it)
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline