There is a disucsison about sunsetting the Chat tool and replacing it with a new JSF/Hibernate Chat Tool.
This is an important discussion as the sunsetting of a tool is as important a process as the bringing up of a new tool.
Here are my thoughts.

I do not like the wholesale replacement of a tool – particularly when there is persistence involved and no database conversion is provided.
Like David I am sure many will immediately use the new chat – but for folks who want to keep things simple, it would be nice to have the *option* to keep the old chat.
Just as an example – while the old chat has demonstrated issues under load – it has years of solid production experience – the new chat was checked in for the first time last week and while it claims to have solved these problems – it might have introduced more problems. Of course QA will likely reveal functional problems – but it would be nice not to have to scramble if some problem is found and have the old chat available to folks at least for one release.
To me this is like Discussion and message center – while Message Center is all shiny and new and Discussion is old and crufty – a surprising number of folks prefer the old and crufty tool.
I think that we should put both chat tools in the release. We could let the new chat tool “take over” the tool id for chat and change the old chat to some thing like sakai.chat1 in its too registration – this way folks get the new chat by default – if they want the old chat wholesale – patch the tool registrations. If they want the old chat on a case by case basis – then they place the chat1 tool.
I just don’t like working code disappearing with zero notice. In a way the removal of code should be done in as considered a manner as adding code. We need a way to make these transitions while allowing folks to make choices in their deployment.
I can see us facing this increasingly in the future as folks start rewriting tools – perhaps in a move to JSF or RSF – so we will need a way to do this in a controlled manner – lets do this one “right” and “clean” so that we establish a precedent for when we do something much more complex like “replace the resources tool” in the future.