Change Details

We have started to create a variety of topics with specific information about events in MediaWiki. The rich event-specific information provided is useful for analytics and many other use cases, but is not typically needed for basic change propagation. The main piece of information for basic change propagation is *what* has actually changed. We currently tend to use the public URL of the modified resource for this purpose. This information alone is already sufficient for a variety of change propagation use cases: - Varnish purging. - Update Parsoid HTML after an edit. - Update mobile HTML once Parsoid HTML for a page has been updated. - Update HTML in other projects after edits to (a part) of a wikidata item. ## Limitations Renames (moves) are traditionally difficult to represent in an idempotent way. However, many change propagation use cases don't actually need to know about the fact that a move happen. Knowing that the old & new location was modified is sufficient to implement all update use cases mentioned above. ## Producing resource URLs to "resource change" topic by default For event producers, it would be convenient if events produced to specialized topics could also implicitly emit an event to the "resource changed" topic, containing the URL required in the event's meta block. Technically this should be relatively straightforward to implement in the EventBus proxy service. We will however need to make sure that events contain sensible URLs. We could consider only automatically forwarding specific specialized topics, to avoid broken URLs in the resource topic.

We have started to create a variety of topics with specific information about events in MediaWiki. The rich event-specific information provided is useful for analytics and many other use cases, but is not typically needed for basic change propagation. The main piece of information for basic change propagation is *what* has actually changed. We currently tend to use the public URL of the modified resource for this purpose. This information alone is already sufficient for a variety of change propagation use cases: - Varnish purging. - Update Parsoid HTML after an edit. - Update mobile HTML once Parsoid HTML for a page has been updated. - Update HTML in other projects after edits to (a part) of a wikidata item. ## Limitations Renames (moves) are traditionally difficult to represent in an idempotent way. However, many change propagation use cases don't actually need to know about the fact that a move happen. Knowing that the old & new location was modified is sufficient to implement all update use cases mentioned above. Some changes might not have existing URLs associated with them. For example, revision suppressions modify revision metadata, but MediaWiki does not define a well-known URL for the revision metadata / restrictions themselves. One option we could consider is to add a little bit of extra information about the kind of change. If the main event was a revision suppression event produced to the `revision_restrictions` topic, then the topic name could be automatically added as a tag to the change event. ## Producing resource URLs to "resource change" topic by default For event producers, it would be convenient if events produced to specialized topics could also implicitly emit an event to the "resource changed" topic, containing the URL required in the event's meta block. Technically this should be relatively straightforward to implement in the EventBus proxy service. We will however need to make sure that events contain sensible URLs. We could consider only automatically forwarding specific specialized topics, to avoid broken URLs in the resource topic.

We have started to create a variety of topics with specific information about events in MediaWiki. The rich event-specific information provided is useful for analytics and many other use cases, but is not typically needed for basic change propagation. The main piece of information for basic change propagation is *what* has actually changed. We currently tend to use the public URL of the modified resource for this purpose. This information alone is already sufficient for a variety of change propagation use cases: - Varnish purging. - Update Parsoid HTML after an edit. - Update mobile HTML once Parsoid HTML for a page has been updated. - Update HTML in other projects after edits to (a part) of a wikidata item. ## Limitations Renames (moves) are traditionally difficult to represent in an idempotent way. However, many change propagation use cases don't actually need to know about the fact that a move happen. Knowing that the old & new location was modified is sufficient to implement all update use cases mentioned above. Some changes might not have existing URLs associated with them. For example, revision suppressions modify revision metadata, but MediaWiki does not define a well-known URL for the revision metadata / restrictions themselves. One option we could consider is to add a little bit of extra information about the kind of change. If the main event was a revision suppression event produced to the `revision_restrictions` topic, then the topic name could be automatically added as a tag to the change event. ## Producing resource URLs to "resource change" topic by default For event producers, it would be convenient if events produced to specialized topics could also implicitly emit an event to the "resource changed" topic, containing the URL required in the event's meta block. Technically this should be relatively straightforward to implement in the EventBus proxy service. We will however need to make sure that events contain sensible URLs. We could consider only automatically forwarding specific specialized topics, to avoid broken URLs in the resource topic.