1. Needs
1.1. Caching Parsoid output
1.1.1. for VE
1.2. Caching alternative output
1.2.1. stable revisions
1.3. Caching other kinds of output
1.3.1. template data
1.4. Caching output for old Revisions
1.4.1. spikes
1.5. old revisions output via REST
2. Problems
2.1. highly optimized code path
2.1.1. Adventures on the Happy Path
2.1.2. this is how people read pages!
2.2. varying on parser options
2.2.1. anon is not for anons!
2.3. Logic not in one place
2.3.1. PoolWorkArticleView
2.3.2. ParserCache
2.3.3. ParserOptions
2.3.4. ParserOutput
2.4. serialization is brittle
2.4.1. forward- and backward-compatibility
2.4.2. potential to bring down the site
2.4.3. PHP serialization surprises
3. Solutions
3.1. JSON
3.1.1. forwards- and backwards-compatibility
3.1.2. needed to update extensions
3.1.2.1. TemplateData
3.1.2.2. GeoData
3.1.2.3. Kartographer
3.1.2.4. Translate
3.1.2.5. ...
3.1.3. JsonCodec
3.2. Serialization Compatibility Test Utilities
3.2.1. store serializations from each each release
3.2.2. ensure we can still read them
3.2.3. check that we didn't change anything by accident
3.3. ParserOutputAccess
3.3.1. Unified for old and new revisions
3.3.2. Unified for views and other use cases
3.3.3. hides PoolCounter logic
3.3.4. Automates caching
3.4. ParserCacheFactory
3.4.1. multiple parser cache instances
4. Outcome
4.1. Everything is JSON now
4.2. Removes blocker to deprecating PHP serialization
4.3. Things are now safe to change
4.4. revision/{id}/html endpoints
4.4.1. uses parsoid
4.4.2. does not yet use parser cache
4.5. Future
4.5.1. full support for parsoid output
4.5.2. full VE backend support
4.5.3. support for caching arbitrary objects
4.5.4. avoid use of global variables