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

[Lukas Fleischer]

On Tue, Apr 12, 2011 at 09:05:05AM -0500, Dan McGee wrote:
> 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.

Yeah, I knew about FS#17583 and I'll put it in the commit message
(regardless of which patch I will finally push).

> > 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.

Ack. Each search result as a "Name" field which can be used to map the
result back to the query.

> > 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.

Yes, this is kinda ugly. I'm not really happy with either of the
implementations but Dan's approach still looks better to me so far.