I would say that this is a legitimate case for un-deprecation. +1
On Jul 13, 2012, at 12:40 PM, Kalle Korhonen <[email protected]> wrote: > Using contentType and response size as a criteria for determining > whether or not to apply gzipping makes a lot of sense when handling > Tapestry responses. However, we just integrated javamelody > (https://code.google.com/p/javamelody/) that's implemented as a filter > and does its own gzipping. You could argue that javamelody should > provide that as a configurable option but currently doesn't. Luckily > it was easy enough to override ResponseCompressionAnalyzer and use > it's deprecated and currently unused contribution as a collection of > paths that should be excluded from gzipping by T5. Just wondering if > others think this is too much of an edge case to support or if we > should put it back in the core and reuse the contribution for excluded > paths? Are there any other valid reasons to disable gzipping on > case-by-case basis than existing resource specific compression and the > size of a response? > > Kalle > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
