https://bugzilla.wikimedia.org/show_bug.cgi?id=4947
--- Comment #16 from Aryeh Gregor <[email protected]> 2008-12-16 23:30:10 UTC --- (In reply to comment #14) > -For efficiency's sake, we should compress images only once if possible. It > doesn't make sense to recompress a SVG 6000 times on every serve (or even if > it's cached.) We should only recompress when the file changes. This will be the case in practice either way, pretty much. The HTTP response (with the compressed version of the file) should be cached indefinitely by Squid. Anyway, as Brion points out, we don't serve actual SVGs on page views and aren't going to start anytime soon: * Limited benefit without IE support, which last I checked looks to arrive in approximately 2027 if Microsoft doesn't invent a proprietary alternative in the intervening time. * Browser support needs to be as fast as rendering a bitmap, so there's no performance regression (this is far from the case right now with arbitrary SVGs). * It would be a pain to do this until we can assume all clients support SVG, because we would have to serve bitmaps to some users and SVG to others. Then we'd have problems with cache fragmentation and inconsistent appearance (depending on the features supported by various browsers vs. our SVG renderer). * Security! We would need an SVG sanitizer that we know is reliable, to avoid script injection and fun stuff like that. So the number of times SVG will actually be served to users is likely to be very low. > -User data, e.g. Wikipedia, has wider scope than live web sites: dbdumps, > cdroms, etc. We need to consider these use-cases as well. Permanent > compression could be a major advantage here. No image dumps exist now at all, do they? If they did, SVGs could be gzipped in the dump (or heavier compression could be used if convenient). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
