That is just *all kinds* of awesome. -- brion
On Thu, Nov 5, 2015 at 1:47 PM, C. Scott Ananian <[email protected]> wrote: > Architecturally it may be desirable to factor our codebase into multiple > independent services with clear APIs, but small wikis would clearly like a > "single server" installation with all of the services running under one > roof, as it were. Some options previously proposed have involved VM > containers that bundle PHP, Node, MediaWiki and all required services into > a preconfigured full system image. (T87774 > <https://phabricator.wikimedia.org/T87774>) > > This summit topic/RFC proposes an alternative: tightly integrating PHP/HHVM > with a persistent server process running under node.js. The central service > bundles together multiple independent services, written in either PHP or > JavaScript, and coordinates their configurations. Running a > wiki-with-services can be done on a shared node.js host like Heroku. > > This is not intended as a production configuration for large wikis -- in > those cases having separate server farms for PHP, PHP services, and > JavaScript services is best: that independence is indeed the reason why > refactoring into services is desirable. But integrating the services into a > single process allows for hassle-free configuration and maintenance of > small wikis. > > A proof-of-concept has been built. The node package php-embed > <https://www.npmjs.com/package/php-embed> embeds PHP 5.6.14 into a node.js > (>= 2.4.0) process, with bidirectional property and method access between > PHP and node. The package mediawiki-express > <https://www.npmjs.com/package/mediawiki-express> uses this to embed > MediaWiki into an express.js <http://expressjs.com/> HTTP server. (Other > HTTP server frameworks could equally well be used.) A hook in the ` > LocalSettings.php` allows you to configure the mediawiki instance in > JavaScript. > > A bit of further hacking would allow you to fully configure the MediaWiki > instance (in either PHP or JavaScript) and to dispatch to Parsoid (running > in the same process). > > *SUMMIT GOALS / FOR DISCUSSION* > > > - Determine whether this technology (or something similar) might be an > acceptable alternative for small sites which are currently using shared > hosting. See T113210 <https://phabricator.wikimedia.org/T113210> for > related discussion. > - Identify and address technical roadblocks to deploying modular > single-server wikis (see below). > - Discuss methods for deploying complex wikitext extensions. For > example, the WikiHiero > <https://www.mediawiki.org/wiki/Extension:WikiHiero> extension would > ideally be distributed with (a) PHP code hooking mediawiki core, (b) > client-side JavaScript extending Visual Editor, and (c) server-side > JavaScript extending Parsoid. Can these be distributed as a single > integrated bundle? > > > *TECHNICAL CHALLENGES* > > > - Certain pieces of our code are hardwired to specific directories > underneath mediawiki-core code. This complicates efforts to run > mediawiki > from a "clean tree", and to distribute piece of mediawiki separately. > In > particular: > - It would be better if the `vendor` directory could (optionally) live > outside the core mediawiki tree, so it could be distributed > separately from > the main codebase, and allow for alternative package structures. > - Extensions and skins would benefit from allowing a "path-like" list > of directories, rather than a single location underneath the > core mediawiki > tree. Extensions/skins could be distributed as separate packages, > with a > simple hook to add their locations to the search path. > - Tim Starling has suggested that when running in single-server mode, > some internal APIs (for example, between mediawiki and Parsoid) would be > better exposed as unix sockets on the filesystem, rather than as > internet > domain sockets bound to localhost. For one, this would be more "secure > by > default" and avoid inadvertent exposure of internal service APIs. > - It would be best to define a standardized mechanism for "services" to > declare themselves & be connected & configured. This may mean standard > ro > utes on a single-server install (`/w` and `/wiki` for core, `/parsoid` > for parsoid, `/thumb` for the thumbnailer service, etc), standard ports > for each service (with their own http servers), or else standard > locations > for unix sockets. > - Can we leverage some of the various efforts to bridge composer and npm > (for example <https://github.com/eloquent/composer-npm-bridge>), so we > don't end up with incompatible packaging? > > Phabricator ticket: https://phabricator.wikimedia.org/T114457 > > Download the code for mediawiki-express and play with it a bit and let's > discuss! > --scott > > -- > (http://cscott.net) > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
