3 ms·
"Luckily"? If the protocol were to catch on, imagine how many terabits of bandwidth would be wasted by such an unnecessarily verbose and redundant protocol. I
by jemfinch 16y ago
"Luckily"? If the protocol were to catch on, imagine how many terabits of bandwidth would be wasted by such an unnecessarily verbose and redundant protocol. Imagine how many CPU-years will be wasted parsing and unparsing the packets. Imagine how much memory wasted because packets can't be processed as they come off the wire, but must be buffered in their entirety before they can be parsed.
This is exactly the sort of thing libraries like Google's Protocol Buffers and Facebook's Thrift were invented for, both of which are open source.
Optimizing for human readability using netcat just doesn't make sense for potentially core protocols such as this one.
- bkudria 16y agoReally? I think they can cross that bridge when they come to it. For now, adoption is critical.
- jerf 16y agoEver gzipped yourself some JSON being used in a standardized protocol? I've got a JSON-based protocol at work for my project and my typical compression ratio on any but the smallest messages with a simple gzip is 16:1. YMMV depending on the exact contents but I don't lose much sleep over the bandwidth. As for CPU years, meh. It's human years that matter. JSON parsing is that big a challenge anyhow. Protocol buffers et al are great, certainly, and they exist for a reason, but not every app needs them and human readability turns out to be very useful in practice.
- zachrose 16y agoWhat's "unparsing?" (Not being snarky. Genuinely curious.)
- loup-vaillant 16y agoThat's serializing: when you go from a data structure to a text file. The exact reverse of "parsing", actually.
- wooster 16y agoThere are a few pretty decent streaming JSON parsers out there. I use yajl for exactly that.
- Rantenki 16y agoXMPP is positively streamlined compared to the bloat in a protocol like say SMTP; have you every looked at all those headers? IRC is simpler, but it has some pretty severe limitations. There are some worse protocols that could catch on (AMQP) ;)
- jedsmith 16y agoXMPP is streamlined compared to SMTP's bloat? Please elaborate on that opinion.
- Rantenki 16y agoSure; XMPP's actual standard calls for a bunch of extraneous XML to get a basic message sent, no argument there. Also, a basic SMTP message calls for very little additional info (ie: to, from, subject, body), however, the reality is that an smtp message from almost any real world provider contains a ton of extra crap. I am not saying that SMTP is inferior in some way, just that in the real world, reliable message delivery isn't as streamlined as we would like. Here is a basic email from shapeways PR: Delivered-To: derek@foodomain.com Received: by 10.216.159.146 with SMTP id s18cs544645wek; Wed, 5 Jan 2011 11:11:57 -0800 (PST) Received: by 10.150.158.4 with SMTP id g4mr22888707ybe.38.1294254716497; Wed, 05 Jan 2011 11:11:56 -0800 (PST) Return-Path: <bounces-1e89d88424-b62849dacd@b.cts.vresp.com> Received: from mkt4-sc.verticalresponse.com (mkt4-sc.verticalresponse.com [74.116.89.111]) by mx.google.com with ESMTP id l18si3840529ybn.44.2011.01.05.11.11.54; Wed, 05 Jan 2011 11:11:55 -0800 (PST) ... redacted another 2055 bytes of crap ... Content-Type: multipart/alternative; boundary="__________MIMEboundary__________"; charset="UTF-8" This is a multi-part message in MIME format. --__________MIMEboundary__________ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And here is where the actual message started...