views:

56

answers:

1

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.

A: 

I think you are re-inventing the wheel. Consider using OpenFire or Tigase which are Java-based and very proven in this IM server space. All the boiler-plate can be leveraged. You tasks would be to add custom behaviors by writing plug-ins.

Khnle
I already looked at this a bit, you're meaning XMPP? But I got no answers if it was worthwhile using XMPP for server-client or would be hard for a custom app (I have extra stuff beyond text-chat) - I;d have to have a customer server app intercepting incoming messages. And also the licensing confused me. Please see this question of mine: http://stackoverflow.com/questions/2904669/how-easy-is-it-to-get-a-custom-xmpp-server-app-running
John
As long as you don't have users sending binary data to each other (custom messages but based on text, even unicode are OK) then I think XMPP is the right way to do. For your last question *if the client was browser-based using HTML/JS...*, you could consider using StropheJS and combine with OpenFire, and add custom XMPP messages, you could build more than just a Chat-type system. I could point to you something I built, but I am not sure if SO is the right place to say it.
Khnle
Pretty sure binary data is a requirement, if nothing else users will want to throw files at each other... and for example Skype lets you have a multi-user real-time whiteboard.
John