Eli Schwartz <eschwartz@archlinux.org>:
Can you update doc/rpc.txt to describe the new version? Looks like the github wiki contains partial work towards this, but it's not in asciidoc format. Sure.
Eli Schwartz <eschwartz@archlinux.org>:
This is a WIP patch, and I'd like to get some feedback before moving on.
There are a few things worth noting: 1. commit 1ff40987 implemented search by depends, checkdepends, optdepends. They are currently left out.
This means we're in a funny situation where in order to get depfields searches we would need to still recommend the v5 interface. Could we implement this as well? If not, we should document it... Of course, v6 should absolutely support what is possible now in v5. The previous patch is more about asking if we can agree on the interface. I'll work on to bring the v6 patch up to date with the new rpc methods supported in v5.
2. v5 allowed searching for orphan packages by leaving out the arg= argument. This is left out as well. 3. as search and info is now a similar concept (and a little different than those in v5), I've implemented them in a separate function. I'd like to know if this is the way to go, or I should try to reuse the existing structure.
2018-06-01 10:50 GMT+08:00 Li-Yu Yu <afg984@gmail.com>:
--- web/lib/aurjson.class.php | 125 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 120 insertions(+), 5 deletions(-)
diff --git a/web/lib/aurjson.class.php b/web/lib/aurjson.class.php index c51e9c2..db11117 100644 --- a/web/lib/aurjson.class.php +++ b/web/lib/aurjson.class.php @@ -20,6 +20,14 @@ class AurJSON { 'name', 'name-desc', 'maintainer', 'depends', 'makedepends', 'checkdepends', 'optdepends' ); + private static $exposed_fields_v6 = array( + 'name', 'description', 'maintainer', 'provides', + ); + private static $exposed_fields_map_v6 = array( + 'name' => 'Packages.Name', + 'description' => 'Packages.Description', + 'maintainer' => 'Packages.Maintainer', + );
Why is this pulling indexes from a map? It's only ever used once, and I don't think listing search qualifiers here really helps code clarity vs. a case statement. I'll fix it.
Moreso when we need to drop the special handling of finding NULL maintainers and don't do provides here because it doesn't fit into the architecture at all. I don't quite get it. Do you mean support for searching by NULL maintainers should be dropped?