On Fri, Nov 6, 2015 at 4:12 PM, Brion Vibber <[email protected]> wrote:
> On Fri, Nov 6, 2015 at 11:13 AM, C. Scott Ananian <[email protected]> > wrote: > > * Hey, we can have JavaScript and PHP running together in the same > server. > > Perhaps some persistence-related issues with PHP can be made easier? > > > > We probably wouldn't want to break the PHP execution context concept that > requests are self-contained (and failing out is reasonably safe). But you > could for instance route sessions or cache data through the containing node > server instead of on the filesystem or a separate memcache/etc service... > Right, exactly. I'm currently running Opcache and APCu inside the embedded PHP which are going to some lengths to offer persistent caches. I'm not an expert on PHP architecture; I suspect there are other places in mediawiki where we are similarly jumping through hoops. Perhaps these could be simplified, at least for certain users. > > * Hey, we can actually write *extensions for mediawiki-core* in > JavaScript > > (or CoffeeScript, or...) now. Or run PHP code inside Parsoid. How could > > we use that? (Could it grow developer communities?) > > > > I'm uncertain about the desirability of general direct JS<->PHP sync call > bridging, in that relying on it would _require_ this particular node+PHP > distribution. I'd prefer loose enough coupling that the JS engine can be > local or remote, and the PHP engine can be either Zend or HHVM, etc. > I expect that I can port php-embed to PHP 7 and/or HHVM without too much trouble, if interest warrants. And I already support quite a large number of different node versions, from 2.4.0 to 5.0.0. And there are some interesting other alternative implementations that could export the same interface but use RPC to bridge node and PHP, see for instance https://github.com/bergie/dnode-php. Even the sync/async distinction can be bridged; if you look at the underlying implementation for php-embed all communication is done via async message passing between the threads. We just "stop and wait" for certain replies to emulate sync calls (in particular for PHP, which prefers it that way). > Of course there are interesting possibilities like using JS as a template > module extension language in place of / addition to Lua. A general warning: > as I understand the php-embed bridge, JS-side code would a) have full > rights to the system within the user the daemon runs as, and b) > exiting/failing out of node would kill the entire daemon. > There is sandboxing within v8, so your warning is not accurate. And in fact, the "mirror image" project is the PHP extension v8js, which I believe Tim started and I worked on for a while before attempting node-php-embed. It also uses the native v8 sandboxing facilities. > PHP-inside-Parsoid might be interesting for some kinds of extensions, but > I'm not sure whether it's better to rig that up versus using looser > coupling where we make an internal HTTP call over to the PHP MediaWiki > side. > Yup. That's what we essentially already do: after starting to implement the template engine in Parsoid, it was scrapped and the entire templating engine is implemented by calling over to PHP to allow it to expand templates. And whenever we want more information about the expansion, we implement it in PHP. But that's essentially the genesis of the "mediawiki as a collection of services" idea -- once you start doing this, you find all sorts of bits of crufty complex PHP code which you'd rather not try to reimplement. First templates, then image thumbnailing, next who knows, probably the skin. One day they might all be spun out as separate services with internal HTTP calls between them. I'm just providing a PoC that lets you ask questions about potential alternatives. I welcome the discussion. > * How are parser extensions (like, say, WikiHiero, but there are lots of > > them) going to be managed in the long term? There are three separate > > codebases to hook right now. An extension like <gallery> might > eventually > > need to hook the image thumbnail service, too. Do we have a plan? > > > > This probably deserves its own thread! > Yeah. Ideally you should only have to write one implementation, and it should be > self-contained or access the container via a limited API. > > I'm not really sure I grasp how Parsoid handles tag hook extensions at the > moment, actually... can anyone fill in some details? > It doesn't basically. It just asks PHP to do the expansion for it, and then wraps the whole thing in an element warning VE not to touch it. Except for citations. On our roadmap for this quarter we have a task to write a "proper" extension interface, and then use it to refactor the citation code and (hopefully) implement <gallery> support. The end goal being to empower the community to write Parsoid extensions for all the large number of *other* tag extensions we don't yet support. Note that Visual Editor needs to be extended at the same time as Parsoid is extended, so they continue to recognize the same DOM structures, and to make the resulting structures "easily editable" in some fashion.. The exact contours of all this is still a research project. This work is, again, a PoC to see if we could allow folks to package their Parsoid extension as an NPM module, and perhaps include in the same module the necessary VE code and hook it up. --scott -- (http://cscott.net) _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
