AUR Metadata Archive (live)

Hello Pamac developers,

We (the AUR development team) are in the process of finalizing a new metadata archive. This kind of archive gives people the ability to search without actually using the RPC type=search API and reducing their requests toward the AUR overall. I have attempted to reach out to one of your developers, however, I wanted to create this issue here so that the project in general is aware and can give more feedback.

Currently, we are considering three slightly different features, a metadata archive containing:

1. (a) RPC type=search formatted JSON data
   • Size: roughly 2.1MB
2. (a) Partial RPC type=multiinfo formatted JSON data
   • Size: roughly 3-6MB (haven't verified this size yet, as we haven't done the modification of the multiinfo format)
   • Contains extended fields: License and Keywords
3. (b) RPC type=multiinfo formatted JSON data
   • Size: roughly 9.5MB
   • Contains extended fields: License, Keywords, all dependencies and package relationships.

The different features are also annotated with an (a) and (b), signifying that we want to make a selection so that there are is only one annotation remaining. Apologies that this... is really organized in a bit of an ugly way here, but I believe this should convey what's going on.

Off the bat, I believe it would be pretty useful for all projects which search through the AUR to have access to 1. This removes the need for API users to utilize the type=search API on local machines when they know they will not be performing a simple request, completely removing the type=search utilization that Pamac may currently use from the AUR's resources.

However, we do believe there may be need for these other extended forms. That being said, a 9.5MB (3) archive might be a bit rough for a client to download; hence, a middle of choice both: 2. This would also include the License and Keywords fields that the type=multiinfo API provides, but not include related packages or dependencies.

In regards to 3, we may also provide this type of format for those who really desire it, but as an extra archive along with the base metadata archive we wish to host. At least, then, users of the archives would have a choice about how detailed they want the archive to be.

All archives on the AUR give out the Last-Modified header and support the If-Modified-Since header, which should be populated with Last-Modified on subsequent requests.

Sidenote: We really do not want to extend archives past what the RPC offers currently, as we believe the RPC offerings should be able to fulfill client needs as it is. However, if there is a good reason to do so, we may consider adding them to the RPC and these archives in general.

So, I have two questions here:

• Out of the current features, which ones do you believe would serve Pamac the best, and why?
• What kind of details would be useful that the current features listed do not have, and why?

Your feedback here is greatly appreciated; we are really trying to come up with a solution that will calm down Pamac's querying toward the AUR, but still give it the ability to perform as it wants.