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

Lukas Fleischer archlinux at cryptocrack.de
Wed Apr 13 11:18:06 EDT 2011


On Wed, Apr 13, 2011 at 08:11:18AM -0500, Dan McGee wrote:
> > 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?

Yes, we had some other discussions on this topic. Our consensus is that
as much functionality as possible should be moved to the client side. I
am not 100% sure here, yet Dan's patch still seems to be the
straightforward and cleaner way to do it to me.

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

I'd personally prefer the second way of doing this. Sounds more like a
clean API.


More information about the aur-dev mailing list