On 06/09/2017 09:57 AM, Gabriel Wicke wrote:
On Fri, Jun 9, 2017 at 12:56 AM, Alexandros Kosiaris <
[email protected]> 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.
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
