>>! In T72148#1230034, @Mattflaschen wrote:
>>>! In T72148#1205755, @Arcane21 wrote:
>> Parsoid is extremely resource intensive, even on small setups, and while the WMF may be able to easily ignore this, many smaller non WMF setups would not be able to do so, and I have to confess I'm greatly interested in introducing Flow to the Orain wiki farm (which I serve at as a staff member), but I'd rather we not have to have to acquire much more resources than we use currently to support Flow.
> 
> To determine whether it's overly resource-intensive, you would have to compare it to other software that does the same thing: Bidirectional conversion of editable HTML to wikitext.
> 
> The reason node.js was used for Parsoid is that investigation showed it was //far// more performant than the same thing would be in PHP.  There's no identical implementation of the current Parsoid in PHP (since no one chose to write one).  However, this has almost certainly not changed.
> 
>>>! In T72148#1211295, @FastLizard4 wrote:
>> With a tool like VisualEditor, it's obvious why Parsoid needs to be required, but I don't see why Flow by itself //needs// to have access to the powerful parsing tools Parsoid provides, especially given that Parsoid is still experimental and is rapidly changing.
> 
> Though VisualEditor is not required (either for wiki operators installing Flow or for individual Flow end users), VE is a key part of the vision for Flow (that's why we use Parsoid to begin with).  That means, for example, we now use VE for previewing (so no preview without Parsoid). 

As to the first issue, I understand that, but we don't WANT to have, need, or require VE at this time, just Flow, mostly because we don't want to be shackled to Parsoid, which we discovered would not scale well to our current resource infrastructure. The WMF can easily use it because frankly they've got resources to burn and them some, but Parsoid (the service backend) is costly to maintain in terms of memory and processor cycles, and while it may be a magical engine that solves a lot of the WMF's problems, it's a resource hog otherwise, and while it works great for VE and the WMF, and I don't dispute that, we and I'm certain almost every single smaller userbase with far less resources to burn does not want to be forced to use something that only the WMF is happy with.

Forgive me if this sounds harsh, but I believe the WMF seems to be proceeding on the somewhat arrogant assumption that if they like something, the rest of the world should easily be able to adapt and emulate it if they want the same, even though the resources needed to maintain it aren't as plentiful on setups far smaller than the WMF's.

Further, as you pointed out, Flow does not currently require it, and while Visual Editor needing Parsoid made sense from the get go (given its intended design and purpose), forcing Flow to conform to the same when it is not strictly required strikes me a little more than railroading non-WMF end users into using something they don't want simply because it make WMF users happy to do so.

As to the second rebuttal, it merely proves my first point: VE is the WMF's baby, and the WMF is intent on forcing everything that hooks into it to use the same standards and nothing else, despite the inconvenience this places on those who do not wish the added expense of Parsoid when the optional hook in feature does not strictly require it.

I understand the WMF wants to make their lives easier, and as a staff member on a wiki server setup myself, I'm sympathetic from an engineering standpoint. However, as an end user of MediaWiki and someone who has to help install, configure, and adjust settings on our setup to work nicely with anything we add, this would be expense in resources to add when as you pointed out it's not a strict requirement, and on a personal note, if adding Flow was merely adding the extension and running the update script without needing a backend that has no real reason to manacled to an extension that was not designed to strictly need it in the first place, I see no reason to make those like myself and others have to suffer Parsoid's presence at our expense when that could be avoided.

I respectfully remind the WMF MediaWiki is global software, and that I feel the WMF should be mindful not all wiki farms and setups are as wealthy in processor and memory resources to burn to maintain the same configurations as the WMF, and since Parsoid is not needed for Flow (which has a negligible resource footprint without Parsoid in tests I have run so far), I see no reason to force others to use Parsoid only when they don't have to.

I'm not opposed to a dual operation standard, in which Parsoid enabled setups can benefit if Parsoid is installed, but if it's not, then it should retain the non Parsoid mode for those who frankly have no desire or intention to ever use or enable Visual Editor.