scottillogical/gist:808301

## gistfile1.txt

On the same topic is we are pushing further into HTTP caching so we've always had features that enables HTTP caching but a lot of people haven't used them. In part because the only user of the HTTP caching was individual clients, web browsers and that doesn't help if you have a thousand users, each one of them is still going to knock in a lot of HTTP caching so people have used other techniques like fragment caching or page caching instead. And what we are doing with Rails 3.1 is shipping with rack-cache which is a caching layer that' built in.

That will enable you to use HTTP caching more intelligently and have it be equivalent to sort of page caching, action caching, or fragment caching in some cases it means thinking about your application a little bit differently but it also means that we will enable using HTTP caching which should work with other caching servers like SQUID or Akamai without having to sort of rewrite your caching layer, so if you go buy Akamai you have already built your application to take advantage of the features that Akamai provides, because we already have it built-in. And something I should add about rack-cache is that when people hear about it for the first time they often think that rack-cache is gonna do all the caching in the heap, in the Ruby heap. And rack-cache is actually smarter than that.

It uses memcache or the file system or redis. And what we're doing for Rails3.1 is we're just going to have rack-cache wherever your Rails cache is, so if your Rails cache is memcache, or redis or file system, we’ll just use that. And that will mean that while there is certain amount of logic of course that happened in Ruby to validate the cache. The vast majority of the thing that's expensive which is just having these huge files will end up being in more sane places. So that's really exciting!

We aren't going to get flushing into Rails 3.1, I don't think. So there is a auto flashing mainly because while we can get it out there , there's a lot of caveat, so we want to really think through and we probably just take the Rails 3.2 release to think through those things carefully. And maybe have a plugin that turns it on and let people play with it a little bit. Active Record has got a lot of performance worked on against it. We 're doing performance work. There's going to be an identity map added in to Rails 3.1 through Ruby summer code project. Engines have got a lot of improvements so that you can more easily build a Rails app and then making an engine later.

There's a sort of a whole bunch of Ruby summer code projects an community contributed features that will make their way in Rails 3.1 and really I think that I would say about Rails 3.1 is that we did a lot of work in Rails 3.0's infrastructure. There are a lot of cool features in 3.0 that you would want to use like Active Record, like Action Mailer, like the Router, but really Rails 3.0 is about improving internals.

And what Rails 3.1 does is really take advantage of those improved internals with a huge number of new features that maybe we would have wanted to get into 3.0 but we had to ship. So a bunch of Ruby summer code projects, a bunch of community contributed stuff, better acts at pipelining and I think. the HTTP caching stuff is something that will probably matter more later than now. So HTTP caching is sort of a similar bet that we made on REST backing Rails 1.2 where Rails 1.2 said "REST makes sense for requests" and Rails 3.1 says "REST makes sense for the sponsors" and while the initial work might be raw, we’re just adding caching support and cleaning up a few of the existing http caching stuff, I think over time there will be additional conventions that emerge, that will make it even better.

I’m actually really excited in general about leveraging http caching better and shipping with the caching layer and I’m excited to see what people do with it. I think just shipping with it is a bet that will be useful, similar bet tool in 3.0 and 1.1 and 1.2.

	On the same topic is we are pushing further into HTTP caching so we've always had features that enables HTTP caching but a lot of people haven't used them. In part because the only user of the HTTP caching was individual clients, web browsers and that doesn't help if you have a thousand users, each one of them is still going to knock in a lot of HTTP caching so people have used other techniques like fragment caching or page caching instead. And what we are doing with Rails 3.1 is shipping with rack-cache which is a caching layer that' built in.

	That will enable you to use HTTP caching more intelligently and have it be equivalent to sort of page caching, action caching, or fragment caching in some cases it means thinking about your application a little bit differently but it also means that we will enable using HTTP caching which should work with other caching servers like SQUID or Akamai without having to sort of rewrite your caching layer, so if you go buy Akamai you have already built your application to take advantage of the features that Akamai provides, because we already have it built-in. And something I should add about rack-cache is that when people hear about it for the first time they often think that rack-cache is gonna do all the caching in the heap, in the Ruby heap. And rack-cache is actually smarter than that.

	It uses memcache or the file system or redis. And what we're doing for Rails3.1 is we're just going to have rack-cache wherever your Rails cache is, so if your Rails cache is memcache, or redis or file system, we’ll just use that. And that will mean that while there is certain amount of logic of course that happened in Ruby to validate the cache. The vast majority of the thing that's expensive which is just having these huge files will end up being in more sane places. So that's really exciting!

	We aren't going to get flushing into Rails 3.1, I don't think. So there is a auto flashing mainly because while we can get it out there , there's a lot of caveat, so we want to really think through and we probably just take the Rails 3.2 release to think through those things carefully. And maybe have a plugin that turns it on and let people play with it a little bit. Active Record has got a lot of performance worked on against it. We 're doing performance work. There's going to be an identity map added in to Rails 3.1 through Ruby summer code project. Engines have got a lot of improvements so that you can more easily build a Rails app and then making an engine later.

	There's a sort of a whole bunch of Ruby summer code projects an community contributed features that will make their way in Rails 3.1 and really I think that I would say about Rails 3.1 is that we did a lot of work in Rails 3.0's infrastructure. There are a lot of cool features in 3.0 that you would want to use like Active Record, like Action Mailer, like the Router, but really Rails 3.0 is about improving internals.

	And what Rails 3.1 does is really take advantage of those improved internals with a huge number of new features that maybe we would have wanted to get into 3.0 but we had to ship. So a bunch of Ruby summer code projects, a bunch of community contributed stuff, better acts at pipelining and I think. the HTTP caching stuff is something that will probably matter more later than now. So HTTP caching is sort of a similar bet that we made on REST backing Rails 1.2 where Rails 1.2 said "REST makes sense for requests" and Rails 3.1 says "REST makes sense for the sponsors" and while the initial work might be raw, we’re just adding caching support and cleaning up a few of the existing http caching stuff, I think over time there will be additional conventions that emerge, that will make it even better.

	I’m actually really excited in general about leveraging http caching better and shipping with the caching layer and I’m excited to see what people do with it. I think just shipping with it is a bet that will be useful, similar bet tool in 3.0 and 1.1 and 1.2.