there are “after” and “around” wrappers, but I don’t think they are easily distinguishable by name etc. The way to go is to think what a handler does and where it fits in the decorator chain.

Wrappers like wrap-params or wrap-keyword-params are clearly useful for the “inner” handlers by doing something to the request map. If something relies on them (e.g. some form processing, like authentication), you need to chain them in the right order.

One example of an “around” wrapper is wrap-flash. If you put something in :flash in a response, next time a request on the same session comes in it will include the same thing in :flash in request.

For example of an “after” wrapper see wrap-content-type. If your response does not include Content-Type, it automatically adds it to the response.

now, are there any “after” wrappers in ring? is there a convention to tell the difference?

And there are other kinds of bloat that I hate with passion. For example, many (most?) modern phones are very slow and perform poorly on very basic functionality. Another example is Firefox: I have a fairly new and powerful laptop capable of running modern games with perfect performance, not to mention regular office/development work. And yet I have to restart Firefox a few times a day because it becomes unusably slow after a few hours of usage.

That hurts me.

The fact that anyone might need Angry Birds makes me sad on another level. I agree with guys like Steve Yegge and Bret Victor that we should be busy making the world better. Not milking it dry, draining money, killing productivity and making the world smaller by selling drugs like Angry Birds or Farmville.

Ok first one is not people need but what we need to be able to deliver faster and often more efficiently then if we would create our own solutions.

Don’t get me wrong – I still am very happy with the conference and crowded halls and toilets are nothing compared to the quality of speakers and all the other things that really matter. I would (and will) do it again.

The issue may depend on what L2 implementation you use. In our case (RMI-replicated Ehcache 1.x) the only way seems to be to launch updated servers in new cache cluster (e.g. on different port). It needs effort and the cache needs to be populated from scratch, but anyway with some manual work it is possible to create a reliable zero-downtime solution for updates.