

Why XMPP Will Be Huge Very Soon - mbleigh
http://intridea.com/2009/2/16/why-xmpp-will-be-huge-very-soon?blog=company

======
bjclark
This guy obviously hasn't actually used xmpp in real life. eJabberd does
really weird things to us when we throw 300-400k messages at it a day.

And this: "XMPP servers, which are essentially make or break an XMPP
application, are rapidly maturing beyond instant messaging."

Have he ever tried to actually debug ejabberd? Cause it's very painful and
time consuming.

Now, I'm not bashing xmpp, it's pretty cool, but it's not exactly "the next
big thing", IMO.

We're actually abandoning it for AMPQ.

~~~
icepick
"eJabberd does really weird things to us".

Describe the weird things, please. I'm about to deploy ejabberd for a
production site, and I'm interested in your experience.

~~~
known
XMPP is XML based and need heavy processing power (for e.g. not suitable for
mobile platform) whereas AMPQ is a binary protocol.

<http://www.deepdarc.com/2008/02/14/mobile-xmpp/>

------
bemmu
When I need to do something realtime, I connect users to my IRC server.
Writing a client for IRC in Flash is very easy, I haven't tried with
Javascript, I imagine you would use a keepalive connection somehow. Am I
missing something by not using XMPP?

~~~
axod
>> "Am I missing something by not using XMPP?"

You're missing hours of headaches working through over-engineered ridiculously
overly complicated horrible XML protocol. Stick with IRC ;)

~~~
clemesha
FWIW, I've had a different experience with XMPP. Take for example XMPP Multi-
User Chat (<http://xmpp.org/extensions/xep-0045.html>) - which outlines a rich
set of interactions between occupants of a room - something I'm really glad
someone else engineered for me. Plus, take a look at the XML stanzas (in the
examples here: <http://xmpp.org/extensions/xep-0045.html>) you are sending to
the server, they're really not that big or complicated. Lastly, with BOSH
(<http://xmpp.org/extensions/xep-0124.html>) and incredible XMPP Javascript
client libs like Strophe (<http://code.stanziq.com/strophe/>), the
possibilities are pretty exciting for web apps.

~~~
axod
A quick skim of the Multi-User Chat though... Firstly, it's 9 years old :/ why
is everyone still not using it? Secondly, you can immediately tell it's
ridiculously over-engineered.

    
    
      <field var='muc#roominfo_occupants' label='Number of occupants'>
        <value>3</value>
      </field>
    

Sorry, but you can't really look at that protocol and say it's not ugly and
verbose beyond reason. The number of occupants in a room is surely used enough
to deserve an encoding of less than 75 characters to specify a _number_.

~~~
jay_kyburz
Isn't that the whole problem with XML

------
axod
Funny, I heard the same argument years ago.

------
nihilocrat
He's missing the main reasons why my company is going forward with a Jabber
server: privacy and reliability.

We are a geographically distributed company that uses ICQ for a whole lot of
communication, so when it goes down for any reason, work just about halts.
Also, we routinely discuss very sensitive things (but we call each other if we
need to discuss root passwords), so a dedicated eavesdropper could learn more
than we'd like him or her to.

~~~
josefresco
Pidgin + OTR FTW

~~~
jerf
Solves the encryption problem, but doesn't solve the reliability problem.

Also, if your company needs to be able to log the IMs for compliance reasons,
that doesn't solve that either.

(Disclaimer: I work for a company that builds IM servers for companies. But...
the above isn't exactly controversial.)

~~~
josefresco
You can still log with OTR, and if you use AOL/ICQ/MSN/Gtalk etc. there will
always be at least one network still kicking.

~~~
there
unless your corporate network's internet connection is down...

~~~
josefresco
Then you have bigger problems. I'd start with a reliable net connection if you
want to do business online.

~~~
there
shit happens. being able to contact someone when it does is important.

i used to work for an isp and we had a private irc server that was very
valuable in the case of outages when we needed to broadcast information to
other departments. if i had to deploy it again now i'd choose an xmpp server,
but either way, relying on an off-network communication server is not a good
idea for a variety of reasons.

------
daleharvey
I think thats missing a big reason, google adopted it.

I have seen a resurgence of applications built on xmpp and instant messaging
in general, I dont think a lot of people will know they are using xmpp, but it
will be lurking in the back

------
mdasen
So, I do think that XMPP will become a much bigger force given the (anecdotal)
rate that post-college students replace their college email with Gmail (and
get Google Talk with it). However, XMPP can't just rest. It really needs to
get Jingle (their VoIP/video protocol) finished and approved and adopted. With
more people looking to use voice and video online, they can't be left behind
because of lack of features.

With Google driving some adoption and (hopefully) smaller IM networks seeing
that XMPP would be in their interests (since it would help them overcome a
lack of users), XMPP could see decent enough growth. However, if other
networks have desired features that XMPP doesn't offer, the interoperability
argument is countered by the lacking of things users want.

------
thwarted
Once I get it working, I love it, but there's two problems I've always had
with getting XMPP working from a programming/developing standpoint, both of
which kept it from going mainstream sooner:

1) there were very few docs that explain the terms (roster, what a conference
server is and why that is different from your regular connect server) in the
context of other messaging protocols (AIM, for example). Yeah, I know now that
"roster" is the equivalent of the buddy list, except it's not because there
are operations that can happen on the roster and it's not complete clear which
component maintains the roster and a lot of roster operations can happen
asynchronously (due do its distributed nature) even when you're disconnected.
None of this was obvious.

2) The docs that did exist, even for abstraction libraries, talked about
creating XML stanzas and the XML stream and all the different XML namespaces
(none of which were explained well enough to know when you would use 'em) and
XML this and XML that. I don't want to write XML, I want to connect to a
server and send and receive messages. That it is XML stream based is beside
the point--and this was always touted as the reason that XMPP was so awesome,
but we all know that it got caught up in the XML hype of the period in which
it was conceived.

Eventually, libraries started being written that provided the correct level of
abstraction for developers rather than protocol designers. Last one I used was
Net::Jabber::Bot (cpan), which was okay, but there's still a lot of data
extraction from partially cooked XML structures.

------
l_frequency
Anyone know of any good XMPP implementations that lend well to implementing
gateways? Preferably in C/C++?

~~~
jerf
Your question is somewhat vague and muddled. Could you clarify what exactly
you are asking for? How are you using the term "gateway"?

~~~
l_frequency
Gateway is as is defined in RFC 3920 Section 2.1

"G1 = A gateway that translates between XMPP and the protocol(s) used on a
foreign (non-XMPP) messaging network"

I don't think my question was not vague at all. It just might be out of the
ordinary. Most people are interested in XMPP client implementations. I want a
pre-existing open-source project that would be a good first step towards
building an XMPP gateway.

~~~
jerf
OK, I wanted to make sure that you were indeed asking for that. While you are
correct that "gateway" is well-defined, _most_ of the time I see it, it is
misused or used vaguely.

So, I can help you out. The only library that I know of that is designed
specifically for the purpose of implementing gateways is Thrasher Bird:
<http://developer.berlios.de/projects/thrasher/> (git at
<http://repo.or.cz/w/thrasher.git> ). I am the lead developer of that library.
While the "sales pitch" is that it wraps libpurple, it is actually designed so
that the "gateway" part of the library is separate from the "protocol" part of
the library, unlike every other gateway I've seen.

It's in Perl, and it's still a bit alpha-ish, but it is also _exactly_ what
you are looking for and in active development, so you'll have to decide
whether that meets your needs.

If you're interested in more information or need help, contact me at
jbowers@barracuda.com . Compiling may be a bit of a chore, but I've managed it
on a couple of different Linux systems now.

~~~
jerf
Actually, now that I think about it, the only thing the C code is there for is
libpurple support; it's all Perl and there's no compilation you'd need to do
at all if you don't want to use libpurple.

------
trezor
Unless I'm missing something totally obvious, many of these reasons might as
well be said for SIP.

