It seems like the `content-html` endpoint is coming soon, so we need to discuss the storage for it. Judging by the name of it, it will store almost full page content in HTML, which is pretty big. Currently, mobile-sections are the second largest table in Cassandra, so obviously we will not be able to just accommodate the whole thing with the current storage capacity we have, so we will need to be creative.
Some questions:
1. What's the rollout plan?
2. Do we even need storage? How quick would the proposed transforms be? What's the performance numbers on it?
3. How much of the transforms are shared between the current mobile-section endpoints and the new content-html endpoint? Is it possible to generate one from another much quicker than from full Parsoid HTML? This one is of the most importance. Given that the clients don't upgrade right away, we're looking into possibly many months/years of supporting both simultaneously, and storing both mobile-sections and content-html is prohibitively expensive.