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

[Dan McGee]

On Wed, Apr 13, 2011 at 6:00 AM, Justin Davis <jrcd83 at gmail.com> wrote:
> We seem to have a fundamentally different conception here. What you
> call "validate" I consider, simply "sorting". You even called it
> sorting in your first paragraph. There is no validation of information
> happening at all. Calling this algorithm "validating" lends it a false
> sense of gravity. It is no wonder you think so highly of it.
Maybe I was a bit extreme in the way I rejected the sorting idea. Here
is why I don't think it should be done:
1. From the RFC [1], assuming objects and ordering is not allowed. "An
object is an unordered collection of zero or more name/value pairs,
where a name is a string and a value is a string, number, boolean,
null, object, or array."
2. What would one do with a query such as
"rpc.php?type=info&arg[]=cups-xerox&arg[]=cups-mc2430dl&arg[]=10673&arg[]=6941"
where there will only be three results, as cups-xerox and 6941 refer
to the same package?

> I am merely suggesting that the server sort the results for the RPC
> user. This makes things easier and more intuitive for the user. In the
> process of querying package info as a whole, you are going to have to
> associate query words with a result somewhere down the road; either on
> the client or server side. Why not do it on the server and save every
> single client the effort?
For one, because anything the client can do it should; there is one
AUR server and 10,000 client boxes. Second, we'd have to ensure we
actually stuck in some sort of error result in the args that we
couldn't locate, and do we duplicate packages found twice?

> How bizarre that you conjure up so many evils of explode-ing simple
> space characters. Yet you don't even mention how you've changed the
> datatype of the "results" field, breaking any code that currently uses
> the info RPC.
Actually, thanks for bringing this up, other than the fashion that you
did- I hadn't realized it until I looked closely this morning.

To the list and anyone else, ideas? Here is what I can think of:
1. If passing one arg, return old style format where results =>
{package}, rather than results => [{package}]. This is pretty bad
though as any client that wants to use the new interface has to still
special case the checking of the returned value.
2. Just make a new "multiinfo" command and leave the old one returning
what it did before.

The ever so slight inconsistency really stinks here, we should write
out a spec on the http://aur.archlinux.org/rpc.php page so this "we
almost all return the same structure but not quite" odd behavior
doesn't happen again.

> I wont be responding again. Feel free to get the last word in.
Way to take the high moral ground and remove any chance of actually
resolving this.

-Dan

[1] http://www.ietf.org/rfc/rfc4627.txt