anticipating the move where thumbnails are *required* to produce direct-access image paths (gallery!):
anticipating the move where thumbnails are *required* to produce direct-access image paths (gallery!):

... so 'MUST go through backend every time' doesn't cut it (as that would require client-side JS based POST activity for each image when a user has propagateDataType=POST instead of GET). Pondering the backend access issues in that scenario means you cannot be certain you'll get a 'thumbnail' callback for every thumbnail produced, UNLESS we move the 'thumbnail' callback into the getThumb() itself --> that would destroy the opportunity to edit the thumbnail creation process using the callback when an icon is produced instead (mime type unequal to 'image/*') --> getThumb() should ALWAYS be invoked for the thumbnails, even when the basic output is an icon instead, due to inability to produce a thumbnail --> all thumbnails, even when they are icons, are always treated as file-specific thumbnails and stored as such (thus possibly producing copies of the icons in the thumbnail cache). More consistent behaviour than the current one, should kill a few conditional branches too, at the very minor cost of extra thumbnail cache space: extra cost is only incurred for non-image files. Plus this move allows us to provide thumbnails for video and audio (album covers, anyone?)

cpojer/mootools-filemanager,cpojer/mootools-filemanager