4 ms·

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 diffe

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

mahmud 16y ago
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.
- vetinari 16y ago
  It is XMPP client, even if used server-side. You still need XMPP server to talk to (ejabberd for example).
- DennisP 16y ago
  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.)
  - jerf 16y ago
    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.)

mahmud 16y ago

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.

vetinari 16y ago
It is XMPP client, even if used server-side. You still need XMPP server to talk to (ejabberd for example).
DennisP 16y ago
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.)
- jerf 16y ago
  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.)