https://bugzilla.wikimedia.org/show_bug.cgi?id=55475
Web browser: ---
Bug ID: 55475
Summary: Make MediaWiki run on Google's App Engine (tracking)
Product: MediaWiki extensions
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Extensions requests
Assignee: wikibugs-l@lists.wikimedia.org
Reporter: mediawiki-b...@nadir-seen-fire.com
Blocks: 2007
Classification: Unclassified
Mobile Platform: ---
From the looks of it Google App Engine now supports PHP.
https://developers.google.com/appengine/
An interesting project now might be to get MediaWiki running optimally on it.
(Ok well, I at least find it interesting even if I never have time to actually
dedicate for this kind of stuff.)
I expect there will be three components involved in this:
* An extension (maybe Extension:GAE to avoid name issues) implementing most of
the big stuff needed.
* Perhaps an mw-config/overrides.php file to make the installer more intuitive
on GAE. Likely bundled with the GAE extension and then required from
mw-config/overrides.php by whoever is installing.
* And a tutorial/manual on how to set it all up and do the App Engine project
configuration that can't be done directly in the extension.
Some specifics about the App Engine's environment:
* PHP 5.4 (yay!)
* Some HTTP headers in the request and response are modified/removed but it
shouldn't create any problems. (eg: Gzip is handled by the App Engine itself
and so Accepts-Encoding is stripped)
* No filesystem write
* No direct socket opening
* Requests are not allowed to run for longer than 60s
* Various system calls are not allowed
* Some notable things come installed:
** Various client libraries for services running on Google's App Engine and
relevant Google services.
** Basic stuff: dom, hash, json, libxml, mcrypt, mbstrinug, openssl, session,
SPL, xml*, zlib
** APC
** memcached, memcached; Both of these are configured "under the hood" to
automatically use the App Engine's memcache service and ignore configuration.
** mysql, mysqli, mysqlnd
* The default php session handler uses Memcache
* A MySQL based database can be provided by the Google Cloud SQL service. Once
permitted an app can access it over a unix socket.
This means a few things:
* ;) the GAE extension gets to use [ 'arrays', 'like', 'this' ]
* Ext: We'll need a file repo for Google's Cloud Storage to do uploads there.
** Google Cloud Storage can do image handling natively so we can skip doing any
thumbnail handling on our own besides making
...\CloudStorageTools::getImageServingUrl calls to get thumbnail urls.
* Ext: We'll likely need an email handler to send emails through the App
Engine's mail system.
* We're still mostly fine for fopen stuff; http:// and https:// have stream
wrappers that make them automatically use the App Engine's URL fetch service
which permits requests to ports 80-90, 440-450, 1024-65535.
* We can't log to file. However using PHP's native syslog will trigger the Log
API that'll log messages that'll be available on the App Engine's console.
* It's optional but there is a built-in handling for Google users that could
easily be used to create an optional mode where logins are done with Google
accounts and App admins are automatically made admin on the wiki.
* Ext: We'll probably want to kill the normal job queue and find a way to
implement it using the App Engine's Task Queues api.
** It is possible to define a cron job that would run runJobs. But Task Queues
are much more intelligent. The service works along with the App Engine's
scaling. If there are no web requests and no tasks the app can theoretically be
scaled down to the point that there are no instances running and costs go down.
While cron would regularly warmup a new instance.
** We'll want to be wary of extensions that add tasks which have job queue
items endlessly add themselves back to the job queue to do cron like things.
* Ext or overrides: Caches should be auto-configured to use Memcache but config
should be ignored/omitted since it's not used.
* We should see which works better; the App Engine's native Memcache sessions
or our Memcache sessions.
The app.yaml contains a handlers: list defining what requests go where. While
it's required to simply define basic functionality. We can also use it to
enable short URLs.
Much of the app.yaml configuration will probably have to be done in a tutorial.
But an includes: list to include some config from other .yaml files is
supported so we could use that to bundle some of the config inside the GAE
extension.
Monitoring our use of SQL queries in simple requests would be a good idea. If
we can find a way to serve simple requests entirely from things like Memcache,
Google Cloud Datastore, and Google Cloud Storage without making a single sql
query (ie: Eliminating the cases when practically the entire request is
SQL-less but we also make one pointless little SQL query in it that completely
messes that up) then we can make is possible for a wiki to run on the App
Engine for long periods of time serving bunches of readers while the Cloud SQL
instances stay off nearly the entire time.
It's a side topic. But Google's App Engine's Mail service actually supports
receiving emails. You can get HTTP POSTs for received emails and even bounces.
May be useful to hook into for any "Email to wiki" extension or feature warning
about user email delivery failure.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
