Arch Linux

A major point of the json query interface was to be as efficient as possible.
We *wanted* to push the logic operations to the client, not have the service doing any uneccesary processing.

This idea does seem fairly sound though.
I will give it some serious thought.

I am gonna expose why i think that rpc.php you have custom fields in the searches.

Preliminar information:
now the clients that query the rpc interface, like arson, have to perform N+1 queries, where N is the number of results.

CLIENT SIDE
From my house each query takes around 600ms. This gives me more than 4 minutes to complete the command "arson -S kde" (421 results -> 422 queries to the aur rpc.php)

SERVER SIDE
I think that 1 request + 1 mysql query is far more efficient that N+1 requests + N+1 MySQL connections + N+1 mysql queries.
Also, if you go to http://aur.archlinux.org/packages.php, you get the expected behaivour. A query takes the expected time, not minutes. But there is one difference: maximum 100 results per page.

DEVELOPER SIDE
Pushing operations to the client is good, but I think think that enforcing N+1 http queries is going too far, specially when what aur-rpc does is not much more than a SELECT to a table/view and the necessary input/output filtering needed in the http world.

USABILITY SIDE
One of the requierements for usability is to avoid unnecessary delays.
Now you get two sources for AUR queries:
a) http://aur.archlinux.org/packages.php - usually takes LESS THAN 2 SECONDS to give you the information you need.
b) http://aur.archlinux.org/rpc.php - usually takes MORE THAN 1 MINUTE to give you the information you need.
So, if you are a developer of an aur client, like i do, option b gets discarded right away.


I hope that with this exposition you understand better what motivated me to develop this patch.

> a) http://aur.archlinux.org/packages.php - usually takes LESS THAN 2 SECONDS to give you the information you need.
> b) http://aur.archlinux.org/rpc.php - usually takes MORE THAN 1 MINUTE to give you the information you need.

I guess it depends on what operation you are performing, and how close you are to the server.

> From my house each query takes around 600ms. This gives me more than 4 minutes to complete the command "arson -S kde" (421 results -> 422 queries to the aur rpc.php)

I have no idea what "arson -S kde" does. I don't use it, so how would I know?
Trying to derive what you are talking about, I can only think about how "pacman -Ss kde" behaves.
"pacman -Ss" only returns a package name and a brief description for the matches.

Are you saying that for every search style query, you also look up the details on each result before returning any results to the user, even if that may not be the package the user wanted information on?

> Also, if you go to http://aur.archlinux.org/packages.php, you get the expected behaivour.

What is the expected behavior?
This is a vague statement.

Let me try to be psychic for a minute, since what you are saying isn't really clear at all...

Are you saying that you want to see the *same information* as you see in the web interface when you get search results?
The (Location,Category,Name,Votes,Description,Maintainer) tuple?

Now *that* is a feature request I could see as reasonable.

Note: I probably wouldn't want to see any join logic (foreign table data) returned in the initial result set though (or at least no complex join data). I don't remember offhand what is being done to generate the aur web search result data.

>I have no idea what "arson -S kde" does. I don't use it, so how would I know?

arson is an aur package search application that uses aur rpc, so "arson -S kde" searches for kde in aur. It returns the same information than pacman -Ss.

> Are you saying that for every search style query, you also look up the details on each result before returning any results to the user, even if that may not be the package the user wanted information on?

Let me correct you: the user almost always wants more information than just the package name when he performs a search, and i don't look up for details on each results, I just add more fields to the same query to the database. (At this point i can't know if Packages is a table or what).

aur-rpc has 2 queries:
to search: SELECT Name,ID FROM Packages WHERE...
to getting info: SELECT ID,Name,Version,Description,URL,URLPath,License,NumVotes,OutOfDate FROM PACKAGES WHERE...

The only thing this patch does is to let you choose what fields you want to get when searching, instead of "Name,ID" (though they are the default to keep backwards compatibility)

> What is the expected behavior?
> This is a vague statement.

> Let me try to be psychic for a minute, since what you are saying isn't really clear at all...

I am not english native, i hope you get more clear understing now.

> Are you saying that you want to see the *same information* as you see in the web interface when you get search results?
> The (Location,Category,Name,Votes,Description,Maintainer) tuple?

> Now *that* is a feature request I could see as reasonable.

Ok, you can take this request if you don't want my patch. It fits my needs. I was simply trying to make something more flexible.

> Note: I probably wouldn't want to see any join logic (foreign table data) returned in the initial result set though (or at least no complex join data). I don't rememberoffhand what is being done to generate the aur web search result data.

If you tell me where i can find the database structure, I can check what logic lives behind the table/view Packages.

PS: Your answer surprised me a bit, because I felt you criticized my patch without knowing what it does and its consecuences. If my previous post offended you it was completely unnintentional. I am not a native english speaker, so I have a limited empathy when i write in this language.

what?
I looked at the patch, and gave an initial response.

*Then* you proceeded to provide a long description, which actually confused me as to what you were asking for.
Sorry if you took the initial response as criticism, but that certainly isn't my fault.

Ok, sorry.