On 06/09/2017 09:57 AM, Gabriel Wicke wrote:
On Fri, Jun 9, 2017 at 12:56 AM, Alexandros Kosiaris < akosiaris@wikimedia.org> wrote:
I also don't think you need RESTBase as long as you are willing to wait for parsoid to finish parsing and returning the result.
Apart from performance, there is also functionality that is missing without RESTBase:
- Diffs are going to contain a lot of extra changes (commonly called "dirty diffs"), as no original HTML or data-parsoid is available to Parsoid's selective serialization algorithm. This might make it difficult to review changes.
What Gabriel said there about dirty diffs. So, this depends on whether wikis are concerned about their wikitext getting normalized to "Parsoid-determined canonical" formats (wrt choice of whitespaces, quotes, for ex.). For example, this is a extremely important for wikimedia wikis, but may be less so for some smaller wikis, if they take a one-time normalization dirty diff and adopt identical norms in source editing.
- Switching between wikitext and visual editing won't work.
This is because of the dirty-diff requirement. As far as I understand, even if wikis are okay with dirty diffs, VE's source <-> html switching functionality requires restbase right now.
- Visual editing in general will very likely stop working once we reduce the size of HTML by separating out metadata (see https://phabricator.wikimedia.org/T78676). We keep pushing this back due to a lack of resources, but it is still planned, and might happen within the next six months.
There are some unresolved questions about how willing (Parsoid) clients are to work with this stripped-html format. That and the matter of us being resource-strapped means we keep kicking this down the road. But, when this happens, this will break VE-editing unless VE and Parsoid hide the data-mw stripping behind a config flag.
In short, using Parsoid directly for visual editing is an unsupported configuration, and is likely to stop working altogether in the foreseeable future.
Just to be clear, we haven't yet made any formal decision to go down this route, but Gabriel articulates the reasons why it might make sense to do this. There are some aspects to consider here: (a) whether we want to support this combination behind a config flag at all given that some functionality may not be available (unless Parsoid clients figure out ways to support some functionality without RESTBase) (b) the complexity (maintenance, testing, documentation, support) of supporting multiple combinations.
We don't have fully resolved answers to this yet. I don't know what VE's take on this is -- so there is also that to consider. But, when we have firm resolutions on all of this, we will make suitable announcements on lists, suggest upgrade options, and update wikis.
But, also, what Gabriel said earlier about RESTBase. If you are already installing Parsoid, adding RESTBase (since it is also node.js) with the default sqlite backend might not be a whole lot more complexity. So, if VE-editing wikis that use Parsoid start adopting this, that would also inform our decisions above.
Subbu.