On 20 January 2015 at 11:08, Rob Lanphier <[email protected]> wrote:
> On Tue, Jan 20, 2015 at 10:54 AM, Mark A. Hershberger <[email protected]> > wrote: > > Tim Starling <[email protected]> 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. [email protected] | @jdforrester _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
