We'll probably want to have more than one class here.

• One that holds the "Parsoid config" and the "Wiki config".
• One that holds the "Page config". Which would include things Parsoid probably currently has no direct concept of like ParserOptions::getCurrentRevisionCallback().

The former would be passed to the Parsoid service's constructor (e.g. in ServiceWiring.php), while the latter would be passed into the equivalent of Parser::parse(). The former is more likely to benefit from caching than the latter.

We could go as far as having three objects by separating the "Parsoid config" from the "Wiki config", but my guess at this point is that in MediaWiki the line between the two will quickly be blurred. as they'll both in the end come from the Config object.

Chances are that details of the caching will be outside of the scope of the interface provided by Parsoid-PHP itself. Instead it would be up to the caller (e.g. MediaWiki) to implement the interface with whatever in-process (e.g. lazy initialization of private fields) and out-of-process caching (e.g. memcached) turns out to be relevant.

In T212982#4859322, @Anomie wrote:

We'll probably want to have more than one class here.

• One that holds the "Parsoid config" and the "Wiki config".
• One that holds the "Page config". Which would include things Parsoid probably currently has no direct concept of like ParserOptions::getCurrentRevisionCallback().

The former would be passed to the Parsoid service's constructor (e.g. in ServiceWiring.php), while the latter would be passed into the equivalent of Parser::parse(). The former is more likely to benefit from caching than the latter.

We could go as far as having three objects by separating the "Parsoid config" from the "Wiki config", but my guess at this point is that in MediaWiki the line between the two will quickly be blurred. as they'll both in the end come from the Config object.

Multiple objects are fine. I Currently, there is a WikiConfig and a ParsoidConfig and env is a wrapper class around them. And agreed, parsoid & wiki config are the primary targets for caching.

Chances are that details of the caching will be outside of the scope of the interface provided by Parsoid-PHP itself. Instead it would be up to the caller (e.g. MediaWiki) to implement the interface with whatever in-process (e.g. lazy initialization of private fields) and out-of-process caching (e.g. memcached) turns out to be relevant.

Great. That matches my expectations as well. And, by design, it insulates the parser code from those details.

Feel free to tweak the task description to reflect evolving details and for improved clarity.

Change 486821 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/services/parsoid@master] Config: Add PHP configuration interface

https://gerrit.wikimedia.org/r/486821

Change 490696 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/services/parsoid@master] Config: Add PHP page configuration interface

https://gerrit.wikimedia.org/r/490696

Change 486821 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Config: Add PHP site configuration interface

https://gerrit.wikimedia.org/r/486821

Is there anything else we want to do for this class (e.g. make an equivalent of JS's "env" object), or should we close this?

A wrapper 'env' class around the different configs (site / wiki, parsoid, page) might still be useful so we can pass one object everywhere where needed.

Change 490696 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Config: Add PHP page configuration interface

https://gerrit.wikimedia.org/r/490696

Change 494530 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/services/parsoid@master] Config: Add Env wrapper class

https://gerrit.wikimedia.org/r/494530

Change 494530 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Config: Add Env wrapper class

https://gerrit.wikimedia.org/r/494530