Client/Server protocol: XMPP versus JSON versus other
Hi everyone. I want to make this specific Wave to tackle this specific
issue. Most people seem to be favoring XMPP so far, but it would be
nice to discuss the merits of each, and hopefully settle this issue
early on.
Both XMPP and JSON have their place already in the Wave world. XMPP is
used for the federation protocol. JSON is used for the actual web
client/server communication right now. However, that JSON is not an
actual spec, and will surely be changed over time. To find out more
information about the JSON used, I recommend using Firefox's Firebug
to look at the requests and responses. When doing this, note that the
JSON standard prefix of "}]}" should be ignored.
Please share your thoughts of which you favor and why.
I'll add a poll as well to the wave-protocol group, but please hold
off on filling it out until you've thought things over thoroughly.
I'm going to moderate this Wave, and remove chatty waves and put
relevant content into this original blip.
XMPP links:
Google Books: XMPP O'Reilly
XMPP site
JSON links:
PyGoWave (they are doing a client/server protocol themselves, and
using JSON)
XMPP
Advantages:
XML Based (almost anyone can parse it)
Already in use in other Wave–related protocols
reduces the quantity of things a prospective wave developer has to
learn
reduces the number of dependencies (at least for wave servers, the
clients don’t care about the part that already uses xmpp)
great for mini–servers, such as one might tie into an existing web
application to integrate waves as a data model for discussion (forums,
blogs with comments, so on and so forth) or as a new data model for
anything else real–time and with multiple contributors (code editors,
other crap?)
Disadvantages:
Can directly extend FedOne's code, so we’ll have to touch Java… and
Google–written code… *shudder* Just because we could extend an
existing codebase doesn't mean we have to. There are lots of mature
XMPP libraries in various languages (e.g. Ruby, JavaScript) which mean
we don't have to go anywhere near Java unless we want to.
JSON
Advantages:
Fairly efficient and compact, much more so than XMPP. Parsing tends to
be faster as well.
Already in use for existing wave client/server communication (but not
in any usable form)
Protocol Buffers
Advantages:
Most efficient, compact
Disadvantages:
Requires c++/Java/python libraries, meaning that other languages would
need to re-implement the proto buffer
Non-Readable(Binary) serialization/deserialization plus API.
Oct 5
Elliott Cable:
I’m fairly balanced between XMPP and JSON. I really love XMPP, but I
sorta dislike XML… I really like JSON, but I’m not sure it’s enough to
balance my love for XMPP.
Maybe we need to develop JMPP for this? d-:
Truthfully, a lot of the XMPP protocol could really be directly
translated to sit on top of JSON instead of XML. JSON objects with
{'type':'whatever'} instead of <whatever/> XML elements… further
object attributes instead of XML namespaces…
meh. too much work, not enough gain. My vote goes to XMPP.
I should note I’m already working on a C/S protocol that layers over
XMPP; but that is no means official. If I finish it or post a draft,
and people decide JSON is a better idea, hey, what the hell, it was
fun anyway. So I highly endorse this discussion and its importance.
Oct 5
William Edney:
Actually, Elliot, in my experience the whole thing about JSON being
both more compact and faster to parse (in a browser anyway) is
folklore (and I worked with/for Doug Crockford back in late 2000 -
he's a good guy, but I disagree with him here). If you gzip the XML
(XMPP), it can actually be smaller in some cases than the JSON. And
JSON was *never* faster to parse (again, in a browser anyway) than
XML. C-based XML parsers have been around a lot longer than C-based
JSON parsers (which have only recently come to browsers in their
latest incarnation - for security reasons you can't really use eval
()...)
Oct 10
[email protected]:
gzipped json is smaller than gzipped xml numbers vary but one source :
states a difference of 10 - 300% larger transfers with gzipped XML,
depending on the size of the dataset, yes comparing gzipped xml to
plain json would be silly. I don't know how you come to the conclusion
that xml is faster to parse, but likely you are referencing how xml
handling is often compiled in while json handling is done via
javascript with the overhead of a few regexs for security reasons,
these are things that are quickly being addressed, as you have noted
yourself.
Oct 5
Elliott Cable:
Yeah, that wasn’t my post, Andrew started this one. I love JSON, but
not because it’s all that much faster to parse; more because it’s more
brain–easy when debugging. I tend to have to really grok the XML spec
for a document to understand a given XML document, but I can usually
understand JSON in any situation. Hence why I love it.
Oh, and I’m a big proponent of JS, not just on the web, but as an
embedded language. JSON has obvious advantages in any such situation.
But none of this really applies here, all that much, and XMPP is just
so cool… and so appropriate, here, due to the real–time element, due
to the already–existing use in the server federation protocol … yeah.
It’s got my vote.
Oct 5
William Edney:
That was another point of mine to folks about XMPP - it's already so
widely used that for a lot of these vendors, they can 'Wave enable'
their existing XMPP software and then sell their customers a 'Wave
upgrade' :-)
Oct 6
Rémy Sanchez:
I also think that XMPP is better... Even though that JSON would be
easier to handle for JS (and then we could do a HTTP binding of the
protocol and have easily pure JS clients running in the browser, which
by the way would be atrociously slow and heavy), XMPP is widely tested
and experienced. And you can handle XML from most of languages. And
there is already a lot that have been done with XMPP (including re-
usable libraries). And XMPP was made to be extensible. That makes a
lot of arguments :)
Oct 6
William Edney:
Actually, XML is pretty easily handled inside of a browser - I've done
a *lot* of it, including writing a lot of XMPP handling inside of a
browser. It's really not that bad (and there are JS libraries to
handle it). I wouldn't want to see the C/S protocol 'corrupted' for
everyone else just because JSON is easy to handle in the browser. Do
the protocol right... us browser guys will adjust :-).
Oct 6
Rémy Sanchez:
Hell yes, and moreover what we want is not at all a web client...
Oct 10
[email protected]:
I dare you to find a reasonably common language which does not have a
json handling lib.
Oct 11
Rémy Sanchez:
Ada has none :)
Oct 11
[email protected]:
well, shucks, you got me, otoh I contend that if someone actually
feels up to writing a wave server or client in ada then this little
bit of work : http://json.org/ won't be much of an issue, especially
in ada.
Oct 6
William Edney:
Well, what some us want is a *different* web client - but that's
ok :-)
Oct 6
Angus Turner:
yes we want a different web client as well, i think people would
prefer a client that doesn't take up 256mb of ram
Oct 6
Rémy Sanchez:
however, I think that doing a thiner web client will be difficult..
After all, Google's got good engineers I think... I hardly belive that
they made a slow and heavy interface on purpose.
Oct 6
Elliott Cable:
I do believe they did. They consider that an okay thing, because they
think of it as a web application, and that changes how engineers like
us think. Somebody setting out to right a light, less–featured client,
that actually runs worth crap, could certainly do so.
Oct 6
✿Melissa✿ Elliott:
Off-topic: It seems all the deleted blips don't show up as being
deleted in the playback. Is this coming Real Soon Now or is the
playback just bugged?
Oct 6
Angus Turner:
i think lars mentioned that when i was speaking to him....
but he didn't say when it would be implemented
Oct 7
Elliott Cable:
Lars was talking about them showing up when you visited first after
they were deleted, not during Playback.
Melissa, sounds like a bug to me. They should already be showing up in
Playback, and have been for me (at least, when I last got Playback to
actually work on a wave, which was something like a month ago, I think
d-:)
Oct 15
Thomas Wrobel:
Speaking personaly, I dont have a preferance for XMPP or JSON...I
think I could adapt well enough to either. As long as theres a nicely
documented standard, that hopefully all wave severs will support, I'm
happy.
Is it time to have a vote box at the top of this thread or too soon?
Oct 15
[email protected]:
well, some of the other threads have moved on and deal exclusively
with how to implement the protocol over XMPP, no need to vote ;)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Wave
Protocol" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en
-~----------~----~----~----~------~----~------~--~---
