Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

CHANGES.md: updated for 2.0

  • Loading branch information...
commit 95f0fa6973aaefff14a5ff4c8af582db6fc5162d 1 parent 40e9df8
Lin Jen-Shin (godfat) authored
Showing with 75 additions and 0 deletions.
  1. +75 −0 CHANGES.md
75 CHANGES.md
View
@@ -1,5 +1,80 @@
# CHANGES
+## rest-core 2.0.0
+
+This is a major release which introduces some incompatible changes.
+This is intended to cleanup some internal implementation and introduce
+a new mechanism to handle multiple requests concurrently, avoiding needless
+block.
+
+Before we go into detail, here's who can upgrade without changing anything,
+and who should make a few adjustments in their code:
+
+* If you're only using rest-more, e.g. `RC::Facebook` or `RC::Twitter`, etc.,
+ you don't have to change anything. This won't affect rest-more users.
+
+* If you're only using rest-core's built in middlewares to build your own
+ clients, you don't have to change anything as well. All the hard works are
+ done by me.
+
+* If you're building your own middlewares, then you are the ones who need to
+ make changes. `RC::ASYNC` is changed to a flag to mean whether the callback
+ should be called directly, or only after resuming from the fiber.
+ And now you have always to get the response from `yield`, that is,
+ you're forced to pass a callback to `call`.
+
+ This might be a bit user unfriendly at first glimpse, but it would much
+ simplify the internal structure of rest-core, because in the middlewares,
+ you don't have to worry if the user would pass a callback or not, branching
+ everywhere to make it work both synchronously and asynchronously.
+
+ Also, the old fiber based asynchronous HTTP client is removed, in favor
+ of the new _future_ based approach. The new one is more like a superset
+ of the old one, which have anything the old one can provide. Yet internally
+ it works a lot differently. They are both synchronous for the outside,
+ but while the old one is also synchronous inside, the new one is
+ asynchronous inside, just like the purely asynchronous HTTP client.
+
+ That is, internally, it's always asynchronously, and fiber/async didn't
+ make much difference here now. This is also the reason why I removed
+ the old fiber one. This would make the middleware implementation much
+ easier, considering much fewer possible cases.
+
+ If you don't really understand what does above mean, then just remember,
+ now we ask all middlewares work asynchronously. You have always to work
+ with callbacks which passed along in `app.call(env){ |response| }`
+ That's it.
+
+It's a bit outdated, but you can also checkout my blog post.
+[rest-core 2.0 roadmap, thunk based response][post]
+(p.s. now thunk is renamed to future)
+
+[post]: http://blogger.godfat.org/2012/06/rest-core-20-roadmap-thunk-based.html
+
+### Incompatible changes
+
+* [EmHttpRequestFiber] is removed in favor of `EmHttpRequest`
+* cool.io support is removed.
+* You must provide a block to `app.call(env){ ... }`
+
+### Enhancement
+
+* The default app is changed from `RestClient` to `Auto`, which would
+ be using `EmHttpRequest` under the context of a event loop, while
+ use `RestClient` in other context as before.
+
+* [Client] `client.head` now returns the headers instead of response body.
+ It doesn't make sense to return the response body, because there's no
+ such things in a HEAD request.
+
+* [JsonDecode] Now we prefer multi_json first, yajl-ruby second, lastly json.
+
+### Bugs fixes
+
+* [Cache] The cache object you passed in would only need to respond to
+ `[]` and `[]=`. If the cache object accepts an `:expires_in` option,
+ then it must also respond to `store`, too.
+
## rest-core 1.0.2 -- 2012-06-05
### Enhancement
Please sign in to comment.
Something went wrong with that request. Please try again.