Compatibility heads-up: prototype != production code
It’s amazing to see how many people are building great things with Astoria so early in the cycle. We talk with folks in the development community often and we hear stories that range from teaching classes, to giving talks, to building experimental systems, all the way to building tools that work on top of Astoria.
Given how much is being built on top of the CTP code, it seems appropriate to set expectations about compatibility moving forward.
The CTP that we released back in May 2007 was a prototype (we called it a “very early experimental release” to make that as clear as possible). The goal was to show a proof-of-concept, see if the idea was interesting for the developers, and obtain feedback about the overall feature set.
When we started to build the real product, we did as everybody says you should, but few people actually do: we threw away the prototype. We want to make sure we produce a world-class code base, of top-quality that is highly maintainable. Also, we want to revisit every design decision and make sure it’s the right one.
The result of all this is that the real code base for Astoria will not be compatible with the CTP. The primary reason is not that we have a new code-base, but that we want to revisit all design decisions and tweak whatever needs to be tweaked. A lot of the changes are coming from feedback from the community, and many others are a result of thinking more carefully about problems (e.g. the prototype did nothing at all about HTTP charset negotiation, to bring-up a low-level detail).
So what will remain the same? The goal is the same: a simple, RESTful service to access data, heavily relying on URIs and using several payload formats so you can pick the one that works on your scenario.
What will change? We’ll do our best to map every possible detail to proper HTTP (charsets, type negotiation, encoding, response codes, etc.). We’ll change the URI format to address the *ton* of feedback we got about it. We’ll also change the payload formats extensively to address both external feedback and other needs.
We’ll start posting the details of each of the these changes in the next week or so, so you can know what’s coming and provide feedback.
Bottom line: continue to build and learn about Astoria, and by all means continue to send feedback. Just make sure you know that lots of changes are coming 🙂