On Fri, Nov 6, 2015 at 11:13 AM, C. Scott Ananian <canan...@wikimedia.org> wrote: > > * Hey, we can have JavaScript and PHP in the same packaging system. What > cool things might that enable? > > * 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... > * 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. 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. 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. > * 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! 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? Note that conceptually we have a few different types of parser tag hook extension: * the standalone renderer (<math>, <hiero>, etc) -- these still need storage for output caching, or CSS/JS/image assets that need serving. These are easy to 'call out' to an external service for, which would make it easy for parsoid to call MediaWiki, or for both to call a common separate rendering implementation. * the standalone wikitext wrapper/modifier (<nowiki>, <pre>, <poem>, <syntaxhighlight>) -- ideally these can be implemented mostly in terms of wikitext transforms :) but may need assets, again, such as highlighting CSS. Again mostly standalone, easy to transform in one place and return the data to be included in output. * the standalone renderer that needs access to the wiki's content and rendering (<gallery>) -- could be implemented as a Lua module I bet! ;) These require back-and-forth with the rest of the MediaWiki system... but could easily be done on the MediaWiki side and output copied into the parsoid HTML. * the state-carrying wikitext wrapper/modifier (<ref>+<references>) -- these require strict ordering, and build up state over the course of parsing, *and* render things into wikitext, and .... well it's just ugly. * weird stuff (labeled section transclusion? translate?) -- not even sure how some of these work ;) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
