To be clear -- I'm not trying to convince anyone that non-sticky sessions are the holy grail of scalability. The advantages of sticky sessions (Igor brought up the cache data locality issue, and there are plenty of others) can easily outweigh the advantages of non- sticky sessions. I just think it's a viable option in certain situations. The more important point is that, imo, a web framework shouldn't dictate scalability choices if possible.
True up to some point. We're all still volunteers meaning that we're mostly working on this on our free time. Even though at least half of the team members use Wicket for our daily jobs, most of the work is done in the evenings and weekends. That is why we don't have client state saving (like e.g. JSF does). It would be possible to implement and while it would probably mean 'selling' Wicket easier in some occasions, we just don't think it is worth our time at this stage, as none of the core developers thinks this would be a better solution than keeping server state. There are advantages to not having to keep session affinity. But there are advantages to having a statefull programming model as well. It's a bunch of tradeoffs in the end, and we have to pick our battles. Eelco
