Our (#services) primary focus this quarter is on enabling change propagation for edit-related events. We already track such events in [a custom extension](https://github.com/wikimedia/mediawiki-extensions-RestBaseUpdateJobs/blob/master/RestbaseUpdate.hooks.php), which then creates custom jobs, which in turn performs HTTP requests to RESTBase. Instead, we would like to cover this functionality with more general-purpose events using the event bus:
- article creation
- article deletion
- article undeletion
- article edit
- article rename
- revision deletion / suppression
- file upload
@halfak has already created a fairly detailed list of events covering this at https://meta.wikimedia.org/wiki/Research:MediaWiki_events:_a_generalized_public_event_datasource#Relevant_events. These should be a great starting point for the discussion.
## Other use cases
- Change propagation between content types
- edit triggers Parsoid re-parse, which triggers mobile app service & metadata updates
- Wikidata changes
- use cases: invalidate pages using specific wikidata items; keeping the #wikidata-query-service up to date
## Considerations / questions
- Naming of articles / resources vs. topics vs. subscriptions: Generally use URLs / paths as discussed in T102476 (section "Addressing of components")?
## Results from meeting 2015-10-22 & follow-up discussion
### Framing, for all events
- **uri**: string; path or url. Example: /en.wikipedia.org/v1/page/title/San_Francisco
- **id**: [v1 UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_1_.28MAC_address_.26_date-time.29); corresponding to the `x-request-id` header, or another primary event identifier. V1 UUIDs contain a high-resolution timestamp.
- **ts**: ISO 8601 timestamp corresponding to the `id` attribute. This is redundant, but makes life easier for human readers, Hive and others.
- **domain**: en.wikipedia.org, fr.wiktionary.org,...; No mobile variants.
### Edit events
- title: string
- pageid: integer
- revision: integer
- savetime: iso 8601
- Other metadata, like the user etc.
- Generally, no overly sensitive information (like client IPs for authenticated edits) in primary events.
- Can be included in expanded message in separate topic, or stored separately based on reqid.
### Implementation
We are hoping to integrate event production directly into MediaWiki core, rather than using an extension and hooks. This functionality should be well integrated, tested & maintained.