On Tue, Jan 20, 2015 at 10:54 AM, Mark A. Hershberger
<mah(a)nichework.com>
wrote:
Tim Starling <tstarling(a)wikimedia.org>
writes:
HTML storage would be a pretty simple feature,
and would allow
third-party users to use VE without Parsoid.
I've been thinking about how to implement an alternative to Parsoid
so that users of MW could use VE without standing up a node.js server.
This gives me hope.
Could anyone elaborate on what VE needs from MW in order to operate
without Parsoid? Maybe there is an architecture diagram I've been
missing?
Funny, we were just talking about that in the office :-)
There are two things that are needed:
1. ContentHandler support for storing HTML. As Tim points out, this
should be reasonably straightforward. I imagine there is a long tail
of small implementation gaps, but a prototype-quality implementation
of this would probably be easy.
2. HTML validation - our current security model relies on the HTML
being generated server-side by a wikitext parser. If we cut wikitext
out of the loop, we'll need some other way of ensuring that people
can't inject arbitrary Javascript/Flash embedding/Java
applet/ActionScript/iframe or any other security horrors.
#2 is a lot harder, and something we need to decide how we want to
implement (e.g. is this something we do in PHP or Node?).
There's also #3 – doing all the dozens of things that the wikitext parser
does on ingestion. All the redlinks and categories tables, building a
user-land (not UI) HTML template system for transclusions, media updates,
*etc.* Not a trivial task.
J.
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester