On Tue, Apr 12, 2011 at 8:52 AM, Justin Davis <jrcd83@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