

XMPP and Social Computing: Let the Bots Talk - fogus
http://www.internetdagarna.se/track/media/social-computing-or-let-the-bots-talk

======
extension
It took a minute to wrap my head around it, but this thing has really got me
thinking: <http://www.linkedprocess.org/>

Summary: XMPP extension protocol to create remote VMs and inject code into
them, language agnostic, asynchronous (you can leave the job running). 

Until now, when I heard "distributed computing", I thought of number
crunching, protein folding, etc.  which doesn't excite me. 

But think of it this way: with a ubiquitous system like this, you are
effectively decoupling applications from resources.  Instead of inventing
formats to serialize data, or protocols to transfer it around, or RPC schemes
to provide remote services, you just make everything available _locally_ in a
sandboxed VM.  Consumers inject code to assemble and transfer just the data
they need, when they need it, with the power to deal with whatever constraints
the network places on their particular use case. 

Creating local APIs, in practice, is _vastly_ easier than creating network
protocols, especially when it comes to cooperation and standards.  So... move
the cooperation boundary to the easy part of the pipeline. 

------
axod
_PLEASE_ Let us do all this with something other than XMPP.  Have we not learnt
by now that the claim of ultimate 'extensibility'!!!  Is stupidity. 

Most buzz words starting with 'X' from the 90s early 00s should be firmly laid
to rest as terrible ideas built on more terrible ideas. 

~~~
riffic
Do you have any specific faults with xmpp or is this rant based purely on
speculation? 

~~~
jerf
I've worked a lot with XMPP in a professional capacity and I have no idea what
his complaint on that front it.  It's _trivially_ extensible; if you control
both ends of the connection, grab a namespace and go to town.  If you don't,
you have to coordinate on the protocol, but XMPP won't get in your way.  You
can't do that with any other IM protocol that I know. ( Which isn't all of
them, but I do know a lot about a lot of them.) 

There are other criticisms that make more sense, mostly to do with the
annoyance of dealing with XML (especially for people that don't actually
understand it; there's a bit more than meets the eye and XMPP actually uses
thing like namespaces) and some valid complaints about verbosity (which mostly
only matters in a mobile context), but there's a lot of other "standard"
criticism that come more from ignorance than understanding, the biggest one
being "complexity"; XMPP is modular, and if you just want to pop open a
connection and send a message that's hardly a day's worth of coding starting
from nothing more than a socket and an XML parser.  If you don't want to be in
a conference room, you don't have to worry about the conferencing standard,
and so on. 

There pretty much isn't another IM protocol that's even in the running for
this sort of use, because XMPP is the only one that actually _is_ extensible. 
The only alternative is specifying a protocol from scratch, and of course that
hypothetical protocol is perfect and awesome... what with it not existing.  Of
course XMPP can't compete with the perfect protocols that exist only in
people's imaginations (and note the plural... no two of them are the same). 
But XMPP actually exists, now. 

~~~
axod
>> " It's trivially extensible; if you control both ends of the connection,
grab a namespace and go to town." 

So what's the point of using xmpp at all?  Why not just use a specific protocol
geared to your use case?  Using your own simple protocol is also trivially
extensible.  And human readable.  Writing a parser for a json like syntax is
also trivial - contrast this with an xml parser which is _not_ trivial. 

~~~
jerf
Go ahead and try it, and you'll find out why. 

Why not use a better protocol to send email?  Why are we still using HTTP to
send web traffic, even though we've really gotten beyond what it is good at? 
Why am I FTP-ing a file even as we speak? 

You're basically asking why utopia doesn't exist.  You won't like the answers,
so I'm not going to bother with them.  All I can say is: Try it.  See how far
you get.  I'm not kidding.  This isn't just a rhetorical device.  Go out and try
to define your own protocol.  See how many people rush over to join in. _ Maybe_
you'll pull off an Atom, but the odds are long. 

(In fact, I _do_ use my own protocol when I control both endpoints, even in a
use case that looks a lot like XMPP, and in fact it _is_ JSON based.  The
project I am working on right now has that as its backbone.  But I know the
limits of that approach.  Bear that in mind as you try to understand where I'm
coming from.) 

~~~
axod
Those protocols took off (HTTP/Email/etc).  The network effect came into play. 

XMPP never really took off (Big surprise).  Using it for new, unconnected
systems, is idiocy IMHO.  There are probably more XMPP extension specifications
than there are people using XMPP. 

I agree, launching new protocols is hard.  You need leverage and a network
effect to get it going.  I do get where you're coming from.  I just think that
anyone who has the choice on what protocol to use for something, and picks
XMPP, is mad. 

Even if it has to interface to legacy systems they could use a bridge. 

~~~
riffic
xmpp seems to have taken off pretty decently from what i've seen so far (rfc
process, ietf backing, adoption by google et al)

~~~
axod
A few big users (Google)... isn't the same as widespread adoption. 

Google could easily switch protocols and provide a legacy xmpp bridge tomorrow
if they chose to. 

~~~
riffic
This is a protocol which has quite a few rfc's associated with it (3920, 3921,
3922, 3923, 4622, 4854, 4979, 5437), as well as being proposed as an official
internet protocol standard on the rfc-editor site.  It isn't going away any
time soon, despite your wishes otherwise. 

~~~
axod
RFCs and other documents do not mean it's needed or wanted - "Make something
people want".  I'm sure it _will_ limp on for years, after all, it's limped on
for 10 years so far without real widespread adoption. 

~~~
riffic
whatever, I presented the evidence that it is on a standards track, the IETF
seems to like it, and it is a better protocol than any of the alternatives. 
I'm sure it is possible that one can come along one day to supplant it, but
for the meantime it is the best we have and it would be nice if people would
adopt a standard rather than whine about it not being done in their way. 

in fact some amazing things might be possible if the service providers adopted
it rather than maintain their proprietary walled gardens.  I would love to be
able to use my google talk account to initiate a jingle session with users on
AIM/MSN/Yahoo/Facebok/etc. 

------
dmix
This article is a "social media consultants" wet dream:

"Lay a foundation for a much more general computing and distribution
infrastructure for context-aware, social-spreadable and trusted application
scenarios that potentially enable users to regain control over their own graph
of information and control access to it using social connections." 

Now, back to reality...

~~~
peterneubauer1
Hi there, being the author of this article, let me just point out that I am
_not_ an "social media consultant" but part of the scientific research carried
out at www.linkedprocess.org.  This article is merely trying to summarize and
relate different computing approaches like Chat, GWave and others.  Much of
what is pointed out in this article is already either in the XEP (which is,
others are actually extending the protocol and requesting these extensions to
be standardized) or projects are exploring these scenarios (see the links in
the comments and the article itself). 

So, I don't think this is reality distortion, Google Wave and others placing
their "next generation conversation" bets into this basket is IMHO a very
fundamental endorsement. 

XMPP is not the tightest of protocols, but it adds a lot of value in the
outlined scenarios since you get internet-scale discovery, status handling,
routing infrastructure and handling of extensions and custom payloads for
free. 

The XML overhead is IMHO only evident if you are either very low on bandwith
(like mobile networks before flat rate and 3G) or parsing the XML yourself
(not using the excellent client libs out there), so I think that is
acceptable.  I agree with some of the other comments that there never will be
an ideal protocol, but this actually works, has exisitng deployments, clients
and libs, and there are open servers and specifications to roll your own if
you like. 

See the piece as a summary, not a roadmap. 

Cheers

/peter

