Session Themes and Topics
- Theme: Architecting our code for change and sustainability
- Topic: Definition of Core, how code fits together, architecture, code encapsulation, FE/BE separation, extension interface
Session Leader
- Timo Tijhof
Facilitator
- Kate Chapman
Description
Extensions are the key way that we add and modify the functionality of MediaWiki. This session looks into the interface for extensions and how they impact the architecture of MediaWiki. The primary goal for this session is identifying (potentially breaking) changes we can make the extension interfaces to enable the underlying architecture to be changed without breaking compatibility in the future.
Would be useful to look at how some other software does extensions. . Two that have recently done overhauls: Firefox, and Wordpress. Both made major breaking changes and invested a lot of effort in this overhaul process. Need to look at what they did, and why.
Question 1: what’s bad about the extension interface that we have?
We expose so many internals that we’re not able to make changes any longer
Restricting the model will allow for changes without destroying existing extensions
Question 2: Is there only one extension interface? Or are there multiple? Can we classify the existing extension ecosystem into a limited number of interfaces that, collectively, cover most of our use cases.
One is a listener, that just receives information
One is a filter, that has the potential to modify, something before sending it along.
One registers additional implementations of existing abstract
Questions to answer during this session
| Question | Significance: Why is this question important? What is blocked by it remaining unanswered? |
| Which functionality should be provided by extensions, rather than core? Which functionality should have a default implementation that can be replaced? | Architecting core to support both Wikimedia and 3rd party use cases is difficult. The Extension interface is the primary way that this is accomplished. Before we can discuss improvements of the extension mechanisms, we have to know what we want to use these mechanisms for. Generally speaking, core should cover functionality that is common to most if not all uses of MediaWiki, while extensions should be used for functionality that is only needed or wanted on relatively few instances. |
| Which properties of the existing extension interfaces makes it difficult to make architectural changes to MediaWiki? What changes can be made to extension interfaces to ease making architecture changes while supporting the functionality needed for extensions? | Many architecture changes that we want to make aren’t easy due to the current extension interfaces exposing a lot of internals. Listing out specific issues will help us define what a better interface may look like. |
| How can the needs of different extensions be classified, and how can these classes of needs be addressed using different kinds of extension interfaces? What functionality of core should be exposed through these extension interfaces? | Identifying the different kinds of interfaces, and their properties and constraints, will guide the design of concrete interfaces, should improve consistency, and avoid exposing internals. |
| If breaking changes are needed, what processes can be implemented to ease such a change? | If we need to break compatibility, we should be clear about what is being broke, why we are breaking it and develop a good migration plan. We should also consider providing compatibility shims where possible. |
Facilitator and Scribe notes
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:
- ...