Property:Description
From atwg
(Created page with "Has type::Text") |
m (1 revision imported) |
(No difference)
| |
Latest revision as of 20:13, 16 January 2018
0
Enable PHP based routing of URLs in MediaWiki to enable REST along with an easy way for developers to specify caching and purging semantics. The routing should be fast and preferably not require all of MediaWiki to be loaded in order to start. Routing patterns should be standard both in and outside of MW. This should be transparent to clients. +
Perform Product and IA analysis to identify which workflows and features to build REST APIs (and PHP APIs) to prioritize first as needed we work to expose more of the full functionality of MediaWiki APIs. +
Design and prototype a REST API that would enable the full functionality of the desktop web experience in MediaWiki Core (and "critical" extensions?) with cacheability and consistent parameters, property names and objects. Note that this highly depends on the overall design of information flow (see [[Output:1.1]]) +
Implement the REST API incrementally by addressing one feature at a time in core +
Research desktop workflows to identify and prioritize workflows to move to mobile. Decide if making Desktop responsive is feasible or if another approach must be taken. +
Implement workflows that respond to both desktop and mobile presentations as identified by research +
Starting from user stories and work flows, identify requirements. Based on available technology and resources, identify constraints. Present trade-offs to PMs and C-Level management for resolution. NOTE: This informs the re-design and refactoring of the API layer, MW core, as well as auxilliary aspects such as Varnish, RESTbase, and EventBus. +
Refactor MediaWiki Core into well encapsulated components, removing global state and circular dependencies between classes +
Incrementallly refactor MediaWiki code into logical classes/components/libraries to isolate functions such as storage, parser, events and app logic. Prioritizing refactoring of code into components to allow: Easier testing (leading to faster development), more easily support both LAMP stack and WMF use cases that require scale and selective SOA, increased re-usability, enabling an API-first approach be de-coupeling the presentation layer. Removing global state also enabled full cross-wiki capability (e.g. loading and rendering content from multiple wikis in a single request). +
Prototype the ability to assemble a page containing both non-personalized and personalized content. +
Separate the routing and storage components of RESTBase into two services +
Profiting from the RESTBase split, create a multi-DC storage component that can serve multiple needs inside Wikimedia's production environment. Use cases include, but are not limited to, Parsoid storage, MCS and others. +
Create a session storage service that uses the storage component and isolate it from the rest of the system using a simple API, and make it easily available from MediaWiki +
Refactor Parsoid to facilitate future port or integration efforts +
Prototype portions of Parsoid in PHP or a PHP-extension supported language to inform parser unification effort +
Unify Parsers into one implementation, deprecating the existing PHP parser. +
Research 3rd party installations to better understand their environments in order prioritize what types of environments and installations to prioritize. Important dimensions to understand include: Bare metal, VPS, Shared hosting, LAMP and LAMx. +
Research and define what a "default" 3rd party installation would be to support. This enables us to better define the work to make installations easier for all parties. +
Improve installation of default MediaWiki for WMF development, testing and production environments as well as 3rd parties (ARCHIVED) +
Implement fixes needed to support the default installation on for environments based on the 3rd party and default MediaWiki research tasks +
Improve installation and deployments of the "WMF Technology stack" for WMF development testing and production environments (ARCHIVED) +
Standardize on the use of containers and Kubernetes for deployment of new services, use containers/minikube to make it possible to reproduce the production service ecosystem locally for developers. Create documentation to introduce developers to this new stack. +
Design and Implement a developer portal to host and centralize documentation for our technology. +
