"You like Strophe.js? You bought a copy of Professional XMPP Programming with JavaScript and jQuery? You even want to use the same XMPP code for the web and node.js? Then you're wrong here: go to xmppjs."
Use node.js conventions, especially EventEmitter, ie. for write buffer control
Fast parsing, node-expat was written with this library in mind
Support for both XMPP clients and components
After authentication, leave trivial protocol bits to the user (later we could offer helpers for entity capabilities hashing, etc)
The other library lets you connect as a component to a XEP-0114 compliant server
Thanks, I read that part too, it still assumes you know what a component is in XMPP which I'm sure most people don't. So it's basically an XMPP client and a "component" (whatever that is)?
Gaah, that's like hitching a trailer to a Lamborghini.
The point of XMPP is to be fat and semi 'standard' complaint. The purpose of node.js is to be fast, at the expense of compatibility and compliance, while maintaining the simplicity of javascript.
If you want XMPP, it might be better to speed up any of its existing servers, instead of saddling Node with cruft.
It looks like a nice library for writing non-blocking XMPP clients and components in Javascript. This seems useful even if the goals of XMPP and Node are different as you claim.
This library does not saddle Node with anything. It's a library for use with Node. It's not part of Node
The point of XMPP clients is to work with a server/platform infrastructure that someone else has built and has control over. Then, it makes sense to use something like Strophe.js to talk to the server in its protocol of choice.
However, if the server you're talking with runs Node.js, there is a good chance whoever behind it (if not you) is someone who is able to make sane technical decisions, like not using XMPP and opting for something light weight.
The way I see, and to use another anology, is like writing a SOAP server in assembly in the hopes of getting better results.
If you want to talk with the myriad of desktop jabber clients out there, use something tried and true, and supports XMPP to the fullest (so Node is out.) If you just want a serialization and pub/sub protocol, use something more lightweight than XMPP. XML manipulation will defeat the purpose of Node, which is performance and design hygiene, very quickly.
Sometimes XMPP is a requirement. Maybe you want the federation, or you want people to be able to use their gtalk accounts.
Call me crazy but I actually think a non-blocking server with good performance and low memory usage would be a pretty nice foundation for an XMPP server. (This project is a client though.)
You're going to have trouble beating ejabberd on its native turf, and JS probably isn't going to let you beat its memory usage anytime soon, based on what I've seen in my running servers. ejabberd is considered a memory hog of an XMPP server, because it might use as much as a kilobyte for a connection's state information, vs C or Java which can go smaller due to full control over the memory. About 200 bytes is more common, though. JS would leave you with even less control over the memory and make it very easy to go ever further over 1KB/connection.
And actually, having experienced ejabberd and worked with its internals quite a lot professionally (for about two years), this is where I think Node.js would just fall down screaming. A serious XMPP server ends up having to do some actual logic that can take some actual time, like working out who is on the roster, which takes time when that may be a couple hundred people. It may still be a fraction of a second, but Node.js is either going to choke and die on the sheer overwhelming number of small little things that still have to be done synchronously, or the XMPP server would have to be manually sliced into tiny, tiny ribbons (instead of working out the roster, working out the next roster item and pushing it out) in which case call overhead would still be a problem too. And being stuck on one core is going to be really rough as you try to scale.
You aren't going to get what the XMPP world would consider "low memory usage" out of Node.js, and "non-blocking" will only get you to toy size. Which may be enough for some tasks since "toy size" is still at least tens of users before you really start hitting these problems, but based on my experience even at the medium hundreds level you're going to start hitting problems.
(The steady-state of an IM server isn't too bad and if we just assume Node.js has somehow made it to the steady state it could support several hundreds relatively easily. The problem is that a real-world IM server ends up getting these spikes that you might not anticipate if you've never worked with them, because events like going online and offline are not independent, and these spikes are what will bring your server to its knees. In particular, there's the case where your IM server itself lost its network connection, then it comes back, and all the clients try to reconnect at once, hammering your server with the full login process for every connected user, full presence storms, complete reconnection of every S2S connection, every transport user reconnecting, basically everything happening all at once, and this is an enormous number of things to be stuck doing synchronously per-item. You will experience the full hell that can be brought to you by cooperative multitasking. The best part is, if your server can't take that process and actually goes down, when it comes back up it gets to start all over again, probably just to crash again. To have a working IM server takes more than being able to handle the steady state, if you can't deal with these spikes your server will have trouble just getting to the steady state. There are some other spikes you can get, too. Also, you'd be surprised at how quickly users pick up on the fact that your instant messages are actually taking 2 seconds to send.)
I was actually thinking redis would handle roster duties. It's got native queries that are a good fit to that sort of thing, and it's got replication in case one instance isn't enough for the load.
There's a guy with a web chat system using Comet on node.js who claims 100K simultaneous users on one server, with fairly modest memory usage. Of course that's http. Is xmpp that much heavier?
(You've convinced me the problem is more difficult than I thought, btw.)
Well, it depends. It is not commonly understood that XMPP is actually very modular. What I was citing you was the requirements for what you might call the "usual" XMPP server, what people tend to expect when they hook up Pidgin or Adium to something claiming to be an XMPP server for dedicated-client use. Huge rosters (in the hundreds is distressingly common, in the thousands not unheard of), server-to-server connections, avatars, conferences, frequent granular presence changes (some % of the users changing for every MP3 they play due to plugins), logging, etc.
On the other hand, throwing together a "shitty" web chat where no one chat room is expected to have more than, say, 20 users, where "chat rooms" are the only communication concept and rosters are more limited or perhaps nonexistent, no logging, sure, Node.js should definitely be able to scale to 100K no problem. Probably beyond with reasonable hardware.
I think you may be referring to Plurk's work, and please note I'm not calling their stuff "shitty", I'm specifically describing a minimal chat client up there. I actually don't think XMPP is all that much heavier than AIM or MSN (some, yes, but not really that bad), it's that IM has evolved past the days of ICQ. What kills you are the O(Roster Entry) elements; one guy with a 2,000 element roster (bidirectional) comes online. With XMPP, as part of the connection process you shove down the 2,000 user roster to the guy logging in, and have up to 2,000 other presence notifications to send out. And it's hard to make that entirely async; even if you do just grab the roster as a lump out of some data store, you still have to iterate over the 2000 elements of the roster to send out the presence updates, and even with GHz to play with that is going to take some time to formulate all the necessary messages. This is what would really worry me at the startup flurry I mentioned.
But like I said, you could still carry hundreds, most likely. Although even then I would observe that the value of having an XMPP server actually in-context to a Node.js process is really pretty minimal. You can still be a "part of the server" via the component protocol which is what you almost certainly really want. Let a best-of-breed do all that for you, and just implement the additional stuff you want in Node.js. Unless you're doing too many O(roster entry) things in there (which in general you aren't in a component), Node.js should scale quite well, and components can typically be sharded cleanly too (by assigning users to shards).
