Brion Vibber <br...@wikimedia.org> writes: > Just to summarize the current state, here's the default MediaWiki > configuration workflow: > > * During page rendering, MediaWiki checks if a thumb of the proper size > exists. > * if not, we resize it synchronously on the same server (via GD or > shell out to ImageMagick etc) > * an <img> pointing to the file is added to output > * The web browser loads up the already-rendered image file in the page. > > > Here's the behavior variant we have on Wikimedia sites: > > * During page rendering, we make an <img> pointing to where the > thumbnail should be > * The web browser requests the thumbnail image file > * If it doesn't exist, the upload web server proxies the request [1] > back to MediaWiki, running on a subcluster which handles only thumbnail > generation > * MediaWiki resizes it synchronously via shell out to ImageMagick > * The web server serves the now-completed file back to the client, > and it's now on disk for the next request
The simpler approach suggested by Nikola seems to be able to address all the needs here without changing the way Mediawiki currently works. The daemon will reply only once to each request after it copied the placeholder to specified destination with the same file name which the daemon later overwrites with the real thumbnail when generating is done silently in the background, no notification reply any more. This way we can get rid of all the complexity asynchronous reply would cause. There will be two places AFAIU where Mediawiki should request this daemon: 1. when the requested thumbnail doesn't exists 2. when user uploads a large image, (to generate an intermediate source image for future resizing), in this case the request object can contain a flag to instruct the daemon to skip the placeholder coping step. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
