(Combining pieces of Jay's thread and pieces of the shared hosting thread.)
Daniel Friesen wrote:
Parsoid can do Parsoid DOM to WikiText conversions. So I believe the suggestion is that storage be switched entirely to the Parsoid DOM and WikiText in classic editing just becomes a method of editing the content that is stored as Parsoid DOM in the backend.
Tim Starling wrote:
Parsoid depends on the MediaWiki parser, it calls it via api.php. It's not a complete, standalone implementation of wikitext to HTML transformation.
HTML storage would be a pretty simple feature, and would allow third-party users to use VE without Parsoid. It's not so simple to use Parsoid without the MediaWiki parser, especially if you want to support all existing extensions.
So, as currently proposed, HTML storage is actually a way to reduce the dependency on services for non-WMF wikis, not to increase it.
Based on recent comments from Gabriel and Subbu, my understanding is that there are no plans to drop the MediaWiki parser at the moment.
Yeah... what is this all about? My understanding (and please correct me if I'm wrong) is that Parsoid is/was intended to be a standalone service capable of translating wikitext <--> HTML. You seem to be stating that Parsoid is neither complete nor standalone. Why?
Currently Parsoid is the largest client of the MediaWiki PHP parser, I'm told. If Parsoid is regularly calling and relying upon the MediaWiki PHP parser, what exactly is the point of Parsoid?
How much parity is there between Parsoid without the use of the MediaWiki parser and the MediaWiki parser? That is, if you selected a random sample of pages from a Wikimedia wiki, how many of them could Parsoid correctly parse on its own? And from this question flows another: why is Parsoid calling MediaWiki's api.php so regularly?
I'm also interested in Parsoid's development as it relates to the broader push for services. If Parsoid is going to be the model of future services development, I'd like a clearer evaluation of what kind of model it is.
Again, please correct me if I'm wrong, mistaken, misinformed, etc., but from my place of limited knowledge, it sounds very unappealing to create large Node.js applications ("services") that closely tie in and require(!) PHP counterparts. This seems like the opposite of moving toward a more flexible, modular architecture. From my perspective, it would seem to only saddle us with additional technical debt moving forward, as we double complexity indefinitely.
MZMcBride