>>! In T72148#1205608, @Mattflaschen wrote:
>>>! In T72148#1179439, @Arcane21 wrote:
>> I strongly disagree with dropping non Parsoid support. Parsoid is incredibly costly, and while I would love to switch my LQT enabled wiki to Flow, I have no desire to install costly backend software to do so, nor would many smaller non WMF wikis with more limited resources, and if it means it performs less optimally, I would consider that an acceptable compromise to retain non Parsoid functionality.
> 
> Costly in what way, exactly?
> 
> * Requires a lot of man-hours to install?
> * Difficult to maintain?
> * Requires high-end services or equipment to run?
> 
> Maybe there's a way Parsoid could be easier for you to use.
> 
> The main reason we want to remove support for non-Parsoid is that it is costly (mainly in software engineer time) to maintain two versions of key parts of the code.

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.

I have also tested Parsoid on a localhost configuration, and I found Parsoid absorbed over half a gigabyte of resources just to function (on a Windows setup, have not fully evaluated this on a Linux at present), and I'm not sanguine on trying to use Parsoid on a wider scale given this resource drain on a small scale.

Also, while I understand keeping around two sets of code is indeed costly to the WMF, I do not see the harm in maintaining such code if it means the extension can be used on non Parsoid enabled setups, as, to be blunt, the WMF provided MediaWiki to the world for everyone to use, and while I understand the WMF wants to tailor this software to fit it's current needs, it could be of great benefit to non-WMF users, and I see no good reason to throw those use cases under the bus just to make one organization happy.

Also, since it is intended to succeed LiquidThreads, and many LQT users on non-WMF setups may wish to migrate to Flow like my organization, I don't see the point in making their task in doing so harder by forcing them to add backend software that consumes a ton of overhead just to use the successor to LQT.