On 4/22/09 11:13 AM, Magnus Manske wrote: > On Wed, Apr 22, 2009 at 12:54 AM, Marco Schuster > <ma...@harddisk.is-a-geek.org> wrote: >> On Wed, Apr 22, 2009 at 12:22 AM, Roan Kattouw<roan.katt...@gmail.com>wrote: >> >>> * Zhe Wu, mentored by Aryeh Gregor (Simetrical), will be building a >>> thumbnailing daemon, so image manipulation won't have to happen on the >>> Apache servers any more >> >> Wow, I'm lookin' forward to this. Mighta be worth a try to give the upper >> the ability to choose non-standard resizing filters or so... or full-fledged >> image manipulation, something like a wiki-style photoshop. > > On a semi-related note: What's the status of the management routines > that handle "thrwoaway" things like math PNGs?
There is no management for this yet, it's done ad-hoc in each such system. :( > Is this a generic system, so it can be used e.g. for jmol PNGs in the future? > Is it integrated with the image thumbnail handling? > Should it be? We do need a central management system for this, which can handle: 1) Storage backends other than raw filesystem We want to migrate off of using NFS to something we can better control failover and other characteristics of. Not having to implement the interface a second, third, fourth etc time for math, timeline, etc would be nice. 2) Garbage collection / expiration of no-longer-used items Right now math and timeline renderings just get stored forever and ever... 3) Sensible purging/expiration/override of old renderings when renderer behavior changes When we fix a bug in, upgrade, or expand capabilities of texvc etc we need to be able to re-render the new, corrected images. Preferably in a way that's friendly to caching, and that doesn't kill our servers with a giant immediate crush of requests. 4) Rendering server isolation Being able to offload rendering to a subcluster with restricted resource limits can help avoid bringing down the entire site when there's a runaway process (like all those image resizing problems we've seen with giant PNGs and animated GIFs). It may also help to do some privilege separation for services we might not trust quite as much (shelling out to an external program with user-supplied data? What could go wrong? :) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
