Our (Services) primary focus this quarter is on enabling change propagation for edit-related events. We already track such events in a custom extension, 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; corresponding to the x-request-id header, or another primary event identifier. V1 UUIDs contain a high-resolution timestamp.
- dt: 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.
- 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.
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.