User "NeilK" posted a comment on MediaWiki.r89918. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89918#c18007 Commit summary:
Use FileAPI for previews when possible. This complicates the situation of when a thumbnail may be generated. Depending on config or layout, it could be any of: 1) Thumbnail wanted before ready 2) Thumbnail wanted after ready multiplied by 1) FileAPI, locally scaled 2) Stashed Image API, remotely scaled, with exponential backoff retries 3) Image API, remotely scaled, with exponential backoff retries And of course all the error conditions! So, I have moved to a different model for obtaining thumbnails, where you just declare that a certain HTML element needs a thumbnail with setThumbnail(), and the framework figures out what it's supposed to do, and the thumbnail should show up eventually (or finally give you a broken image and an error condition). The thumbnail framework is now using a pub/sub model with a twist; certain events can happen only once, and you can subscribe to them in the past. This is a little bit like the 'ready' state of some DOM elements, so these are called by 'publishReady' and 'subscribeReady'. Think of it as "publish that we are now ready to show this thumbnail" or "do this action when the thumbnail is ready (or right away if it already is)". Comment: Although we discussed this in person, I changed my mind -- I don't think it should be a FIXME. It's more like a missing feature with UploadWizard. Originally, I deliberately excluded the file-rotation code because I found it hard to follow, and I still think it should be cleaned up a bit. And throwing in new dependencies on Canvas and a different form of file reading may not be a good idea just before our deploy this afternoon. So, okay to mark this OK? I have created a new bug instead. (bug 29383) _______________________________________________ MediaWiki-CodeReview mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
