[wp-trac] [WordPress Trac] #64596: Abilities API: Allow nested namespace ability names (2-4 segments)

[WordPress Trac]

#64596: Abilities API: Allow nested namespace ability names (2-4 segments)
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  AI                |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:                    |     Focuses:
------------------------------+-------------------------------

Comment (by justlevine):

 @jorgefilipecosta While I'm all for reverting the commit before beta1 so
 we can have more time review, discuss, and iterate, I would strongly
 recommend **against** rushing to ship the functionality as a single-
 namespace into core without a real conversation about what good
 usage/holistic API looks like. I'm on mobile which is making it hard for
 me to dig up and share all the prior discussion in the different core-ai
 silos, but step 1 here is getting core contributors and committers up-to-
 date with the feedback loops that happened prior to Trac, not to throw it
 all out with the bathwater.

 IMO this is the whole reason we have an AI Experiments canonical plugin,
 so if we can't reach consensus before the B1 cutoff, **''I'd strongly
 suggest we iterate there and not push a potentially compromised API to
 core WP7.0''**.

 (Broader side note, I think going forward we need to be a lot more
 conscious to create Trac tickets upfront with our `wordpress-develop
 Abilities API PRs`, and out of our `WordPress/ai` Issue bubble -
 especially if when we aren't first releasing them via an Experiment).


 -----

 >> This is too restrictive for organizing abilities into logical resource
 groups.
 > Isn't organizing abilities into groups why Ability Categories exist?

 To be pedantic, Ability Categories exist because folks on the team felt
 there would be _some_ eventual need for taxonomic grouping, and if a
 solution wasn't squeezed into the 6.9 deadline and we instead waited until
 we had a holistic use case, then we'd need to deal with the `$default =
 'Uncategorized'` backcompat problem that the built-in post Category
 taxonomies have.

 (I believe the last 3 months has proved that to be an _implementation_
 mistake, and hopefully this entire thread will serve as a stronger
 argument about shipping speculative functionality to Core, where it's then
 unintentionally used as "prior art" that prevents holistic iteration. cc
 `extends \WP_Ability` and the pre-6.9 merge discussion about top-level
 props versus `meta` nesting, for when I return with the receipts).

 Regardless, and potentially redundant to what @jorgefilipecosta already
 noted, the architectural purpose of is also different. Nested namespaces
 aren't about semantic categorization but about routing, discovery,
 hierarchical control, scope encapsulation, caching, etc etc. No matter how
 Abilities Categories evolve over time it will always exist in the metadata
 plane, as it a potential solution to an entirely different set of problems
 that we can't deduplicate without compromising the schema-based isolation
 that Abilities are premised on.

 > The dev note from when abilities was introduced states that these are
 namesapaces that aim to prevent conflicts. This is inline with blocks and
 the rest API. Introducing a new way for slashes to be used introduces
 unnecessary differences between abilities and other apis in core.

 @jorbin Can you clarify your argument here and perhaps your broader
 concern with slug fragments (consumption, docs, dx, aesthetics, something
 else?)

 1. While I think there's a _lot_ of inaccuracies in that dev note (sadly
 it wasn't shared for team review before it was published), I don't think
 it's fair to consider `Use namespaced names to prevent conflicts (e.g.,
 my-plugin/my-ability)` as philosophically prescriptive. Not do I think
 that it would somehow preclude or even contradict having additional (still
 unique) sub-fragments in an ability name.

 2. Indeed blocks (+ currently templates/partials and patterns) don't
 support slug fragments, but I'm not sure why we'd want a functional type
 safety primitive to mirror a design hydration API. As for REST I've got no
 idea what you mean - ''of course it supports nested namespaces''.  Not
 just the base concept: `/wp-json/{namespace}/{version namespace}/{endpoint
 namespace}/{selector namespace}` but even implement in core we've got off
 the top of my head we've got Post Revisions `wp-
 json/wp/v2/posts/{selector}/revisions` and Block Directory Search at `/wp-
 json/wp/v2/block-directory/search`. [[br]][[br]] Other programmatic
 aspects of WordPress that support slug fragments to the same purpose as
 #61062: [[br]]
   - Routing via Pretty Permalinks & the Rewrite API
   - Hierarchical Post Types and Taxonomy terms
   - Hooks (Supported, and a very popular pattern in plugin ecosystems,
 just not adopted internally unless you count SCF)
   - Official PSR-4 based libraries like Requests, PHP AI Client (in
 addition to serving WP internally, both these libs and abilities are
 intended to integrate with non-WP-ecosystem integrations).

 So yeah, IMO both necessary and fairly aligned - I'd go as far to say
 intuitive / complimentary and definitely not in conflict - with anything
 in core.

 -----

 > If we are looking for a way to give core provided abilities better
 prominence, than perhaps what should be explored is a _built_in flag
 similar to post types.

 Hope I made it clear that's not one of the considerations behind nesting.
 But just in case it's a concern elsewhere:

 We can get this information directly from the root namespace `core/` with
 0 additional effort or API footprint. (This parallels REST, where `wp-
 json/wp/v2` gives you a list of all the available Endpoints in the
 namespace+subnamespace). Sadly, it looks like the API to query abilities
 won't make it in time for 7.0 so folks still need to `array_*()` the
 registry for ''any'' discovery or enumerative prominence, but that's not
 impacted by the availability of an extra class prop or meta field that
 just serves as a flag.

 -----

 Hopefully the above dump was enough to keep the discussion unblocked and
 moving - at least until I can come back and drop any
 aforementioned/requested receipts (my current 5h/w week volunteering
 doesn't seem to be enough for lorekeeping, working on it 😅).

 @jorbin if you're keen and have the time, I'd love to catch you up on the
 prior art/decisions and any other questions you might have in slack/call
 before we bring things back here for further discussion/decision, could
 shave off a good amount of async back-and-forth and improve the chances of
 us reaching consensus in time to bring in some new core Abilities for 7.0.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64596#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform