On Tue, Apr 12, 2011 at 8:52 AM, Justin Davis <[email protected]> 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
