Brainstorming: Arguments, Contexts, Relationships and Access Rules/Conditions API?

hello

Should Butler have Contexts API, Access Rules/Conditions API and Relationships API?

This idea comes from the following rationale:

* CTools module provides Contexts and Access Rules. Additionally, Arguments and Relationships might be provided by CTools.

* Panels is a great module that uses CTools extensively, by exploiting Contexts and Access Rules (Rulesets), and also Arguments and Relationships, the Page Manager and AJAX framework (which got implemented on D7 core).

* Views (3.x) currently depends to CTools. #646284: Status of Views 3 Roadmap:
I haven't examined the code, but it seems plausible that Views will use/uses Contexts and Access Rules from CTools, as well as the Page Manager (read somewhere), and maybe got/will get the Arguments and Relationships from it, or keep the code for that from 2.x.

* Context module, which requires CTools, provides a way to arrange blocks, by using Contexts/Conditions. I'm not sure how this relates to CTools or if Context module uses just the AJAX framework and little more. The module tries to replace the Blocks system (or complement it).

btw, regarding that, Block 2.0 and Boxes have similar approaches, but have nothing to do with Contexts, Access Rules, etc.

* Panels Everywhere requires CTools for it's Contexts and Access Rules (and Relationships?), and also Panels and anything it requires or uses from CTools (like Page Manager and AJAX framework). This is a solid solution, yet complex, to replace entirely the blocks system, like Context module does.

* Rules uses Conditions to determine whether or not to execute Actions or Rule Sets (think core Actions module), when a Event (think core Trigger module) is fired. Rules also deals partially with Arguments. This module was made to replace Actions and Triggers from Core, and other similar modules - and effectively it does - Full Events/Triggers and Actions is already implemented in Rules. It also integrates with Token, a module that was moved to D7 core.

Also FYI, the Trigger module from core is being removed in D8 core, but is still retaining the Actions module. #764558: Remove Trigger module from core

Noting that in Drupal contrib:

* Arguments is a way to pass simple arguments to a page or module (...);
* Contexts is a way to pass contextual information to modules and pages (CTools vs Context);
* Relationships combines/relates pieces of content, like Node Author with Node ID (Drupal itself does some of these relations automatically, perhaps that is not optimal) (Core vs CTools);
* Events is a scheduled, machine or user action, that can be used to trigger something (Core Triggers vs Rules Events);
* Access Rules sets a way to define on which condition something will happen (CTools Rulesets vs Rules Conditions);
* Actions is a given command/action, to be called given certain events and/or conditions (Core Actions vs Rules Actions/Rule Sets);

Some conclusions:

a) it would make sense to have Butler deal with anything that is SESSION, Arguments, Contexts and Relationships;
b) Access Rules/Conditions:
....b.1) move to Butler (makes sense IF rules is not in core);
....b.2) move to Rules (implemented partially? fully?);
c) Events/Triggers:
...c.1) move to Butler (being removed from D8 core);
...c.2) move to Rules (fully implemented already);
d) eventually deprecate and remove Actions module from core (D9?) so that Actions is dealt by Rules module only:

I'm thinking A + B1 + C2 + D, because it's not very likely at the moment that Rules will get into D8 or D9 core, and some of Access Rules code needs to live in core, so it might live instead in a unified way in Butler if Rules does not get in core. #1211396: [META] Getting started with Rules 8.x

By doing this, we could effectively remove these pieces of code from miscellaneous places in Core (moved to Butler API in core), Rules, CTools and Context modules, and any other modules that use custom code, like perhaps Domain, OG, etc.

Then Rules, Context, Panels (thus Minipanels and Panels Everywhere), Views, etc could plug into Butler to get the relevant APIs and do their thing.