On Sat, May 7, 2011 at 4:41 AM, Will Pierce <[email protected]> wrote: > I don't want to start a flamewar, but the fact is that JSON is the "new XML" > and is frequently treated AS THOUGH it is a "self-describing protocol".
from my point of view, the main difference between JSON and XML is that with XML comes an entire ecosystem of truly miserable code and horrible API design -- probably because the rise of XML happened to coincide with the "silly years" in Java. JSON never rose high enough on anyone's agenda to attract the attention of people interested in blessing it with an "infrastructure". as for self-description I'd say that in most *practical* cases, XML and JSON are about equivalent in scenarios where the XML is not presented along with a DTD or a Schema. JSON makes for a bit less visual noise though -- and for users of Algol-derivatives, it probably speaks clearer to the part of the brain that interprets visual structures :-). > I > don't want to preach to the choir, but the advantages of Thrift over JSON > are numerous and proven, at least in the context of working with skilled > software developers. (How many times have these so-called "REST APIs" > changed their JSON output in backwards-incompatible ways, I cannot count... Thrift does not make you immune to versioning problems -- you just end up with different versioning problems. in my case the versioning problems arose from the fact that we were developing a service that exported a Thrift API and was a Cassandra client at the same time. while our internal Thrift APIs were using a newer version of Thrift (which generated different code), the Cassandra servers were using an older version of Thrift -- and not even a properly versioned one at that. just some revision from the SVN repos. this meant that we had to either accomodate two different Thrift versions in the same JVM or we had to revert all our APIs back to an older version of Thrift, change all the client code that depended on newer a Thrift version and then re-do everything when Cassandra eventually switched to a newer Thrift version. (if memory serves, this had to do with the presence of the "private-members" option in the newer version but not the older. the code in question was started off on a newer version so to switch back to the older version we had to change the code) any protocol binary compatibility doesn't really mean all that much when you are generating code and the API of the generated code changes. it also doesn't help you much when you suddenly depend on two different library versions in the same (Java) binary. in any case, a comparison between Thrift and REST/JSON is a comparison between apples and oranges. they have entirely different characteristics. > I think it's possible you expected too much of your Windows-using customers, > or expected Thrift code to be more production-ready than it was at the time > (or is today). you are making an argument for not using Thrift. I just thought I'd point that out :). I think the main thing we misjudged wasn't how mature it was (or immature) but the fact that progress was a lot slower than we'd hoped. we had also hoped that we would find the time to contribute to Thrift. > I suspect the root problem was that for a long time, Thrift didn't really > have "versions"... It had SVN _revisions_ (snapshots)... while this wasn't a big problem for us initially, it was a big problem for us when using other projects that depended on thrift since they'd use severely outdated versions. Cassandra suffered a bit under this to the point where I think they wanted to ditch Thrift and replace it with Avro and then decided against it (?). (ironically, if Cassandra had ditched Thrift and removed the dependency entirely it would have made using Thrift a lot easier for us). > I don't mean to question your claim, but I'm surprised that the version of > Thrift (libraries or compiler) would make a difference to a client for an > application that speaks Thrift. it does when your code otherwise ends up depending on two different versions of the library. > My single greatest criticism with the Thrift codebase is that the RPC > implementations (services) are generally fragile (at least in Python and > Perl). Since I started with Thrift so many years ago, that RPC > implementations were still being developed for many target languages, I and > my coworkers developed an RPC mechanism on top of Thrift that doesn't depend > on the TProcessor, or TServer types. If I were to start anew, I would > probably look at the java THsHaServer to begin from, but that's just > personal bias. I don't use Python myself, but I think I would have looked for an asynchronous network IO library to build on rather than reinvent one. I've done NIO-based networking frameworks in the past when Java didn't have any decent NIO-based abstraction libraries that were usable. Today, for Java, there's Netty, which would arguably have saved a lot of work and offered access to far more features for free. (I don't remember when either Netty or Mina were released, but they are around now and I think that for the Java version Netty should be given serious consideration. it is a dependency worth having for Java) > And honestly, since I've been using Thrift for over three > years, I can't really complain about the RPC implementations. If it was a > serious problem, I would contribute code to fix it. As it stands, Thrift > lets you implement your own RPC if you want to, the same as ProtocolBuffers > and JSON over HTTP. > > I hope this helps. Sharing my own experience, I don't mean to contradict > anyone else's. I would love to hear more stories of how folks have used > Thrift to solve their problems, and where it hasn't worked well. If > anything matters, it's that we can all learn from others' experiences. I > hope my story helps. the sad thing about thrift is that too few people have time to contribute to it and the barrier for doing dramatic changes is a bit high. both because there is a lot of software out there that depends on Thrift, but also because you need to cover a lot of different programming languages and platforms to make changes. and it is an open source project so people don't want to seem ungrateful (and rightly so). -Bjørn
