This arguments are very very old (I have read the same in 2005).
The problem discussed there are not true anymore, at least.
We have deployed really large scale XMPP networks and I can tell you that it works fine.
As you said, the protocol support compression and the fact that some clients or servers does not implement it is not a problem in the protocol.
On your other remarks, you should try using it. The best thing in XMPP is that it is extensible. It uses XML for that (and namespaces). Other approach could probably have been used, but the end result is that it is simple and that you can extend the protocol to do anything you want. Really. That's what make it an XMPP application server possible. You can develop extension that will simply be ignored by client not supporting it.
This is why you can build a complete infrasctructure on it that allows to mix human and machine in a single workflow.
If you knew me better, you would know that I do not like XML at all. SOAP is bloated, WS-* specifications are bloated. But XML use in XMPP is one of the clever use of XML I have ever seen.
Actually, ejabberd is probably one of the highest performing XMPP server. It can supports tens of thousands of simultaneous connections on a single node and can work in a cluster. That's for a single domain, but with distribution as described in the protocol, each web site is his own domain.
As you see, the scalability is handled. And on the raw message performance, it can handle hundreds if not thousands of messages per second in a cluster.
What about OneTeam ?
OneTeam is working on all platforms with a Firefox 2 browser. It offers a native user friendly interface. Only our MSN gateways have been plugged for now, as it is in public beta and we will open gateways one at a time.
I am participating to OneTeam development but I am suggesting it here because it is still little know and we are working on improving it every day, so if you have feature requests, suggestions, criticism or praise, it is very welcome:)
The forum to comment is here: http://www.process-one.net/en/forum/viewforum/9/
Debugging Functional languages can be quite messy and of course i don't know of any good debugging utilities for languages like (S)ML that are purely function in approach.
I think this is not true.
You should give a try to the Erlang functionnal language. Their debugger is really amazing. Really useable and even really useful as a learning tool.
Slashdot Mirror
See ejabberd home page.
This is a flexible and powerful XMPP server written in Erlang.
This arguments are very very old (I have read the same in 2005). The problem discussed there are not true anymore, at least. We have deployed really large scale XMPP networks and I can tell you that it works fine.
As you said, the protocol support compression and the fact that some clients or servers does not implement it is not a problem in the protocol.
On your other remarks, you should try using it. The best thing in XMPP is that it is extensible. It uses XML for that (and namespaces). Other approach could probably have been used, but the end result is that it is simple and that you can extend the protocol to do anything you want. Really. That's what make it an XMPP application server possible. You can develop extension that will simply be ignored by client not supporting it.
This is why you can build a complete infrasctructure on it that allows to mix human and machine in a single workflow.
If you knew me better, you would know that I do not like XML at all. SOAP is bloated, WS-* specifications are bloated. But XML use in XMPP is one of the clever use of XML I have ever seen.
You have also a couple of books on Jabber (before it was called XMPP). They are a bit outdated but it can help you a lot.
Actually, ejabberd is probably one of the highest performing XMPP server. It can supports tens of thousands of simultaneous connections on a single node and can work in a cluster. That's for a single domain, but with distribution as described in the protocol, each web site is his own domain. As you see, the scalability is handled. And on the raw message performance, it can handle hundreds if not thousands of messages per second in a cluster.
zemp sounds nice indeed.
Yes, please, go the Touchstream way. I am looking to buy one, but the product has been discontinued after Apple bought the company ...
What about OneTeam ?
:)
The forum to comment is here: http://www.process-one.net/en/forum/viewforum/9/
OneTeam is working on all platforms with a Firefox 2 browser. It offers a native user friendly interface. Only our MSN gateways have been plugged for now, as it is in public beta and we will open gateways one at a time.
I am participating to OneTeam development but I am suggesting it here because it is still little know and we are working on improving it every day, so if you have feature requests, suggestions, criticism or praise, it is very welcome
OneTeam web client is in beta on http://oneteam.im/
If you need an example of functionnal programming used in real life, you should give a look at Erlang web page:
www.erlang.org
This language is used by Ericsson as a strategic advantage in their software business.
Debugging Functional languages can be quite messy and of course i don't know of any good debugging utilities for languages like (S)ML that are purely function in approach.
I think this is not true.
You should give a try to the Erlang functionnal language.
Their debugger is really amazing.
Really useable and even really useful as a learning tool.
Check:
http://www.erlang.org/