Session Themes and Topics
- Theme: Architecting our code for change and sustainability
- Topic: Turning data into HTML (beyond the parser)
Session Leader
- Raz
Facilitator
- John Bennett
Description
As MediaWiki moves towards an API-first architecture, we need to maintain compatibility for legacy clients as well as extensions that still produce HTML directly. In this session, we’ll discuss when, where and how data gets turned into HTML, and what compatibility layers are needed for this.
Questions to answer during this session
| Question | Significance: Why is this question important? What is blocked by it remaining unanswered? |
| When, where, and how is data turned in to HTML in MediaWiki (other than in the parser itself)? | Obviously, the wikitext parser is the primary way that data gets turned in to HTML within the context of MediaWiki. SpecialPages and Action handlers are other ways. Enumerating the paths that result in rendered content is a necessary step towards an API-first world. |
| While we move towards an API-first architecture, how do we serve consumers that do not support client side rendering? | For the foreseeable future, we will need to support clients that do not support client side rendering. To do so, we need to decide where the rendering can happen for such clients, whether it can use the same code/templates as the client side rendering, how it is cached, etc. |
| While we move towards an API-first architecture, how do we handle extensions (and core code) that cannot be quickly ported to serve JSON instead of rendered HTML? | Changing application logic from emitting HTML to emitting data structures is a gradual process. Client side rendering mechanisms will need a mechanism to integrate HTML generated by legacy code. |
| When implementing client-side rendering, how do we minimize callbacks to the server side API for miscellaneous tasks like rendering localization messages? | One major roadblock for client side logic has been the fact that MediaWiki’s localization mechanism is based on WikiText, and needs a WikiText parser to function. Listing alternative and options for this issue is essential to planning the migration to an API-first architecture. |
Facilitator and Scribe notes
- https://docs.google.com/document/d/1eb6omjp0MF4bsfvnr-bWzsK7O3EyUVSO_JmdY7nJ_kY/edit
- https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2018/Session_notes/Mapping_our_data_and_content_pipeline
Facilitator reminders
Session Structure
- Define session scope, clarify desired outcomes, present agenda
- Discuss Focus Areas
- Discuss and Adjust. ''Note that we are not trying to come to a final agreement, we are just prioritizing and assigning responsibilities!''
- For each proposition [add etherpad link here]
- Decides whether there is (mostly) agreement or disagreement and the proposition(s).
- Decide whether there is more need for discussion on the topic, and how urgent or important that is.
- Identify any open questions that need answering from others, and from who (product, ops, etc)
- Decides who will drive the further discussion/decision process (ie: a four month deadline)
- Discuss additional strategy questions [add etherpad link here]. For each question:
- Decide whether it is considered important.
- Discuss who should answer it.
- Decide who will follow up on it.
- Wrap up
Session Leaders please:
- Add more details to this task description.
- Coordinate any pre-event discussions (here on Phab, IRC, email, hangout, etc).
- Outline the plan for discussing this topic at the event.
- Optionally, include what it will not try to solve.
- Update this task with summaries of any pre-event discussions.
- Include ways for people not attending to be involved in discussions before the event and afterwards.
Post-event Summary:
- ...
Action items:
- ...