User:EvanProdromou/WebHooks

This is a rough sketch of a separate way to build extensions for MediaWiki.

Problem

There are two problems that our current hooks system does not solve.

• Building extensions in a programming language other than PHP
• Services at scale that run out-of-process and/or across the network

For the first, we already have some techniques, but using a network interface may be the most flexible. Having an out-of-process interface means you can write your code in whatever language you want.

Interface

The proposed solution is to use a webhook pattern to augment our existing Hooks tool.

A method could be provided to register a new service that provides a collection of webhooks:

wfRegisterService('http://owntidy.localdomain/register');

The endpoint used to register the service would return a JSON object mapping hook names to webhooks:

{

"ParserBeforeTidy": "https://owntidy.localdomain/parserbeforetidy",

"SoftwareInfo": "https://owntidy.localdomain/softwareinfo"

}

When these events happen inside MediaWiki, the webhooks will be called with the hook arguments as an array of JSON-encoded values:

[

{

// Parser state here

},

"<div><p>My dog has fleas.</p></div>"

]

Alternative one: The webhook can return false, a string, or anything else, JSON-encoded. This has the same effect as in-process hooks.

"No fleas found."

Alternative two: the webhook can return an object with the return value plus the modified arguments:

{

"return": false,

"arguments": [{/* parser state...? */}, "<div><p><span class='content'>My dog has fleas.</span></p></div>"]

}

Notes

This structure could probably be implemented by an extension today.

It assumes synchronous calls to the remote service.

It would probably add significant overhead to any extension, but extensions that already do network access (like using a database) wouldn't have a problem.

It doesn't allow access to the MW global state. This is a bug or a feature, depending on how you look at things.