Update: totally re-wrote this to be more succint.

I'm looking at a new application, one part of which will be very similar to standard IM clients, i.e text chat, ability to send attachments, maybe some real-time interaction like a multi-user whiteboard.

It will be client-server, i.e all traffic goes through my central server. That means if I want to support cross-communication with other IM systems, I am still free to pick any protocol for my own client<-->server communication - my server can use XMPP or whatever to talk to other systems.

Clients are expected to include desktop apps, but probably also browser-based as well either through Flex/Silverlight or HTML/AJAX.

I see 3 options for my own client-server communication layer:

1. XMPP. The benefits are clients already exist as do open-source servers. However it requires the most up-front research/learning and also appears like it might raise legal issues due to GPL.

2. Custom sockets. A server app makes connections with the clients, allowing any text/binary data to be sent very fast. However this approach requires building said server from scratch, and also makes a JS client tricky

3. Servlets (or similar web server). Using tried and tested Java web-stack, clients send HTTP requests similar to AJAX-based websites. The benefit is the server is easy to write using well-established technologies, and easy to talk to. But what restrictions would this bring? Is it appropriate technology for real-time communication?

Advice and suggests are welcome, especially what pros and cons surround using a web-server approach as compared to a socket-based approach.