[aur-dev] [PATCH 4/4] rpc: allow multiple args on info query

[Dan McGee]

On Tue, Apr 12, 2011 at 8:52 AM, Justin Davis <jrcd83 at gmail.com> wrote:
> Tuxce submitted a similiar patch awhile back:
> http://mailman.archlinux.org/pipermail/aur-dev/2010-November/001349.html
> The patch file isn't on the mailing list but I have it in my inbox still.
Looks quite similar, although mine is part of a bigger overhaul and
not a one-off change to just the info method. I didn't even know it
existed. Lukas, if you end up going with mine it should probably
reference FS#17583.

> I remember because I added a few patches to it. Are packages returned
> in the same order that their names are given?
Hold up. This is absurd- you are dealing with a JSON dictionary, not a
server-side sorting web service API. There is not and *should* not be
any guarantee of order.

> I remember this was a
> problem with Tuxce's patch (which I patched). What about queries that
> do not match any results? Will the array of results be smaller than
> the number of queries? From reading the first patch in this thread, it
> seems that if IDs and names are used as query args their order is lost
> because they are split into separate arrays. When using WHERE IN do
> the results match the order of query arguments? Because we are
> returning a JSON array, order is important to associate results with
> our query.
Strongly disagree. Using the keys (package names) associated with each
grouping of data is. Validate what you get back and stop trusting the
server.

> I like using spaces better and don't see how they could have a
> different meaning in msearch. It seems like spaces would have a
> similar meaning when used in args to msearch (splits keywords for
> msearch, names/ids for info). It's not really a big deal though... I
> can live with the ugliness...
So you're saying for two of the three, we should support spaces? Talk
about a maintenance and API nightmare if this implementation ever
changes again down the road... Your calling code either works as
before, or you change it to pass arg[] keys instead of arg keys. I
hate the syntax but it also doesn't make sense to resort to
non-standard URI parsing just for the sake of it.

> Just playing the role of devil's advocate here. Yay RPC overhaul,
> thanks Dan! Yay maintainer names in RPC results!
>
> PS I wonder how many of those rpc.php?type=info queries are from keenerd? hehe!
It would be great if we could tell, but AUR helpers (which are easily
those 50% of requests providing no UA below) are not helping:

   5644 curl/7.21.3 (x86_64-unknown-linux-gnu) libcurl/7.21.3
OpenSSL/1.0.0c zlib/1.2.5
   6548 curl/7.21.3 (i686-pc-linux-gnu) libcurl/7.21.3 OpenSSL/1.0.0c zlib/1.2.5
   7916 Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.16
(KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
   8810 Mozilla/5.0 (compatible; Yahoo! Slurp;
http://help.yahoo.com/help/us/ysearch/slurp)
  11435 Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.16
(KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
  12561 Mozilla/5.0 (compatible; discobot/1.1;
+http://discoveryengine.com/discobot.html
  14148 Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20110321 Firefox/4.0
  14691 msnbot/2.0b (+http://search.msn.com/msnbot.htm)._
  16215 Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)
  24141 Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20110321 Firefox/4.0
  25643 cower/3.x
  29614 Wget/1.12 (linux-gnu)
  31149 Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
  49861 LuaSocket 2.0.2
  51514 Python-urllib/2.6
  70160 curl/7.21.4 (i686-pc-linux-gnu) libcurl/7.21.4 OpenSSL/1.0.0d zlib/1.2.5
 105992 curl/7.21.4 (x86_64-unknown-linux-gnu) libcurl/7.21.4
OpenSSL/1.0.0d zlib/1.2.5
 518447 -

-Dan