edsgar dijkstra could have been talking about SOAP when he said:
“The design of new formalisms, more effective because geared
to our manipulative needs, is neglected because the clumsiness
of the current ones is a major motivation for the mechanization
of their use.
It is not only the performing artist who is, in
a very real sense, shaped by the instrument he plays; this
holds as well for the reasoning man, and I leave it to you
to determine how disturbed you are going to be by this observation.”
Ryan Tomayko,
Its nice to read such a way of expressing the technology, but my wife never cares when I talk about it. Any way it was helpful to undestand
The diagrams were made using websequencediagrams.com. If you view source, you'll see how they were created using a simple text format embedded in <pre> tags. There’s a useful guide as well.
One minor nitpick, in the Expiration section, the image shows the return of max-age=600, then in the paragraph following you state that the content is valid for 5 minutes. 600 seconds is 10 min.
There are solutions for printing to PDF from a webpage…#14 above or by installing PDFCreator and just printing to that PDF printer.
I just installed a firefox extension that allows me to print webpages from the command line…I can choose a printer, pdf or png…‘Command Line Print’. The extension uses Gecko.
http://torisugari.googlepages.com/commandlineprint2
This is great, because I created 300+ static webpages that I'd like to print and bind into book form. Now, I can just create a script file instead of navigating to each page to print it.
Very good explanation of how REST works, Mr. Tomayko. I do wish you had added the context information in the article, perhaps at the beginning, and, in complete agreement with what Andrea said above, that you had used your wife’s name, and an example that had to do with her job as a teacher, rather than to show her as the “little ignorant housewifey” who does nothing but gossip with her sister and mom, clean the house, and “GET” things for you, if not, alas, your jokes.
I did find the sexism so blatant that it was distracting, and definitely detracted from what could have been the best and simplest explanation for it.
This is nice — I will show it to my wife as she is also a teacher (a linguist) and is interested in computers and computer languages. I'm a web programmer myself.
I see why some might think it sexist, but I find that very misguided really — you and wife obviously have a good relationship for her to sit through that, and she must have good self esteem not to feel condescended to or just plain confused when you are discussing very technical aspects of your work with her. Would that everyone could be this way with their partners.
As the band Live would say, “We came to the earth to graze”. No reason not to resist learning.
LMAO! I didn’t find it sexist at all; it just happens to be a technical man explaining to a non-technical woman. I think it was great how he dumbed things down for the layperson to understand. It reminds me of working in the computer labs when I was in college, trying to explain why users' documents didn’t magically save to their floppy disk when the computer went BSOD. :) (Ok, that was before auto-save, but still…)
“Fact is, it’s a very common scenario as described in this post. If the author would have pretended to be a woman explaining it to her non-tech husband, it would only be patronizing, if anything, and you'd have to be naive to buy it.”
Im sorry, but sometimes I think it also happens that a tech girl explains things to her non-tech boyfriend, so I think your comment is the only sexist thing here. If there are not more women in technology is because of guys like u, who make them feel as freak weirdos. The post itself is not sexist, and its amazing: well done!
Yes, I'd very much like to work on a generic HTTP caching test suite. Rack::Cache has a decent set of unit tests but I really wish there was something that was external and operated at the wire protocol level.
Also, I've edited the post to be more clear on the trade-off between Rack::Cache and a high-performance intermediary (s/overhead/infrastructure investment/).
I totally agree that for most devs getting a cache like Squid up and running is a difficult, unappealing task, for the reasons you state (also, Squid for one isn’t too friendly to typical Web devs, as its core audience is sysadmins and network folk). While we can work on these platforms to make them easier to understand and work with (I've been dipping my toes in here), it’s still a big leap for most.
One of the problems that I've had in getting caching adopted is that by the time people think of it, it’s too late; they've already designed and coded their resources. The fact that it’s hard to get them a cache to work with from the get go only complicates this.
So, making caching easier to integrate into apps from the beginning — by building HTTP caching in to the frameworks — is a fantastic, very smart strategy to make sure that when people need that high-end scalability, they can transition easily, by interposing an intermediary (still one of the great strengths of HTTP IMO).
Thanks for the clarification (I only saw technical overhead, not social/management overhead when I read that), and kudos!
I'm also heartened by the IMS/INM validation support that’s starting to show up; earlier frameworks tended to do the simple thing and just compare a hash of the content after generating it, thereby incurring all of the cost still. Newer ones (including this, AFAICT) are being much smarter and allowing validation to “see” inside of application semantics to shortcut that.
Let me clarify: when I said “overhead”, I was speaking specifically about the time and research involved in getting a separate caching daemon up and running and then managing it and not about the machine resource overhead involved. I should have been more clear on this.
As you mentioned, a separate, high performance gateway cache has massive performance and resource use advantages compared to something like Rack::Cache. Unfortunately, I'm afraid the complications involved in scaling these systems down is hurting adoption of more advanced HTTP caching techniques because the benefits are unattainable without the investment (headache) of managing another large piece of infrastructure. So caching becomes an afterthought – something you learn about only after you've made the investment in a high performance gateway cache. Rack::Cache aims to make the benefits of HTTP caching available very early and broadly, even if in a diminished capacity. I suppose its something of a worse is better approach.
I do think the performance improvements created by something like Rack::Cache can be extremely compelling for the types of web applications I've been dealing with for the past few years. A typical Ruby web app performs lots of database reads (often with multiple round trips) and heavy string manipulation. The sophisticated web and ORM frameworks bring large productivity gains and ease maintenance but there’s a lot of extra code to move through and the layers of abstraction often sacrifice performance for simplicity. On top of all that, we're running on one of the slowest interpreters in existence.
What all that adds up to is significant resource (especially CPU and memory) use in generating a full response. I'm finding that, in a great many cases, I can generate cache validators in 1/10th – 1/50th of the time required to generate a full response due to less DB interaction, string operations, and just spending less time in the framework. With something as simple as Rack::Cache, it’s possible to build my app such that my backend never has to generate the same response twice (within resource limits, of course).
None of these arguments support Rack::Cache over a high performance daemon or CDN. But Rack::Cache makes the benefits available in some form for much less cost. And the beautiful thing is that your app has been built with standards from the beginning so moving up to a high performance system should not involve major application-wide changes to your backend codebase. The systems are complimentary.
Also, systems like Rack::Cache might not make sense in other environments. The value of such a system is directly proportional to the average amount of resource use required to generate a full response compared to that required to generate cache validators. A PHP app that performs direct, hand-crafted SQL queries and doesn’t use a template engine might not see the same increases because the difference between generating full responses and validators is negligible. But a Ruby app that uses an ORM and makes tens of thousands of method calls per request is just ripe for massive gains because generating cache validators is significantly less work than generating a full response.
It’s great to have more cache implementations; there are few around, mostly because it’s actually a fairly complex thing to implement well.
However, I was somewhat surprised by your statement “…without the overhead of a separate daemon process.” To me, this is the fundamental limitation of this kind of of approach (whether it be in Python with WSGI or Django, or here in Ruby); concurrency.
Any modern Web proxy/cache implementation is built to be massively concurrent, based upon an event loop. The limited functions of a proxy/cache are actually a huge win in this respect; because they only ever need block on disk access and network access — both things that can be factored out on modern OSs — it’s possible to make assumptions in your architecture and get massive scalability and performance wins.
In contrast, getting good concurrency in a dynamic language takes a tremendous amount of programmer discipline, and even then it’s very difficult to get performance and scalability close to an order of magnitude less* than the approach above. And, of course, if you're running on Apache — as most people will be — you pretty much throw any serious amount of concurrency out of the window.
So, the “the overhead of a separate daemon process” is IMO a mistaken characterisation. In my day job we run a lot of servers this way; dynamic code on the back end, fronted by a Squid process to speed things up. It works — and scales — remarkably well.
By no means do I want to discourage you from taking this route — as I said, it’s great to have more implementations — but realistically, it will never perform as well as a separate Squid, Varnish, etc. OTOH, it will be easier to integrate new features into your cache; we've been doing that progressively in Squid for a while now, because it didn’t meet a lot of our needs, but of course it’s a slow process.
Great explanation. I was at a tech talk about WCF and how it relates to REST and thought, hmmm, what exactly IS REST all about. I googled and found your post, Great.
As far as the comments about sexism, personally I would disregard. If in fact, the conversation happened, well it happened. How is that sexist? I've explained many things to my wife (in laymen’s terms) and she has a CS degree. She’s explained many things to me (in caveman’s terms), and I'm humanoid too. So what gives?
Finally, my wife has sat and listened to me go on and on about something and I don’t think that she is really interested, I think that she simply loves me, and guess what, I love her back for it!
This is exciting! I've written a micro framework called Gossamer using Rack and memcached. I've been thinking lately of removing the explicit dependency on the cache, possibly by using a front-end cache like squid. But it seems that your Rack::Cache would get me most of the way there, and be more cleanly implemented in Rack — as well as being less of a deployment pain.
Bob: Absolutely. There’s a TODO list and I'm open to any and all features/bug-fixes that would bring the system further into line with RFC 2616. It’s very much still an experimental project so nothing’s totally out of the question. There should be enough code there to set the tone.
I appreciate changes in the form of links to git repos with discrete commits and good commit messages but I'm also happy to accept patches via email. The easiest thing is probably just to fork me on GitHub.
name on Top.app
comment5,
Thu, Nov 20, 2008 at 05:40 AM #
Kppokwau on So, What Does "HREF" Stand For, Anyway?
good material thanks sextv =–))
Thu, Nov 20, 2008 at 05:22 AM #
Fmmfkfpu on So, What Does "HREF" Stand For, Anyway?
i'm fine good work porntv flash >:DD
Thu, Nov 20, 2008 at 02:24 AM #
Xmowslwt on So, What Does "HREF" Stand For, Anyway?
I love this site free porntv streams 38194
Wed, Nov 19, 2008 at 11:33 PM #
Oulblnmi on So, What Does "HREF" Stand For, Anyway?
sextv online 67518
Wed, Nov 19, 2008 at 08:42 PM #
name on Top.app
comment1,
Wed, Nov 19, 2008 at 07:19 PM #
Rxijtjoi on So, What Does "HREF" Stand For, Anyway?
Gloomy tales Free sexmovies :[[[
Wed, Nov 19, 2008 at 05:54 PM #
Hiymccye on So, What Does "HREF" Stand For, Anyway?
It’s serious free xxxtv >:(((
Wed, Nov 19, 2008 at 03:07 PM #
wwwoyunlar1com on Top.app
comment2, hilton sheets, 8DDD, doubletree carbon monoxide, >:[[, novotel kuching, =–]]],
Wed, Nov 19, 2008 at 02:18 PM #
ranking hotel chains on Top.app
comment3, hospitality industry problems, 665802, cendant hotel franchise, :))), jose ibarra and rent paris now, 997,
Wed, Nov 19, 2008 at 01:26 PM #
Richard Slater on Things Caches Do
Thank you, a very well written primer.
Wed, Nov 19, 2008 at 08:36 AM #
Kamal on Things Caches Do
Thanks, I like this way of explaining with diagrams.
Wed, Nov 19, 2008 at 07:07 AM #
fdfdfd on How I Explained REST to My Wife
edsgar dijkstra could have been talking about SOAP when he said:
“The design of new formalisms, more effective because geared to our manipulative needs, is neglected because the clumsiness of the current ones is a major motivation for the mechanization of their use.
It is not only the performing artist who is, in a very real sense, shaped by the instrument he plays; this holds as well for the reasoning man, and I leave it to you to determine how disturbed you are going to be by this observation.”
Tue, Nov 18, 2008 at 05:04 PM #
dfguy on Rails and Scaling with Multiple Databases
what plugins or gems are you using to create PDFs in Ruby? Can you provide any example in a future article?
Tue, Nov 18, 2008 at 11:06 AM #
Bharath Kumar on How I Explained REST to My Wife
Ryan Tomayko, Its nice to read such a way of expressing the technology, but my wife never cares when I talk about it. Any way it was helpful to undestand
Tue, Nov 18, 2008 at 08:11 AM #
orip on Things Caches Do
Thanks for the explanation and the links!
Tue, Nov 18, 2008 at 05:58 AM #
Mohammed Faizal on How I Explained REST to My Wife
Thanks for the explanation bro. So there are people who can explain it in simple words.It was really very helpful.
Tue, Nov 18, 2008 at 04:40 AM #
Natán on Things Caches Do
Nice :–) Thank you.
Tue, Nov 18, 2008 at 02:26 AM #
Ranjeet Walunj on Things Caches Do
Great explanation …. thanks for all who have given informative comments.
Keep up the good work. thanks
Tue, Nov 18, 2008 at 02:05 AM #
Bob on Things Caches Do
Thank you. Explains it well.
Tue, Nov 18, 2008 at 01:46 AM #
Ryan Tomayko on Things Caches Do
The diagrams were made using websequencediagrams.com. If you view source, you'll see how they were created using a simple text format embedded in
<pre>tags. There’s a useful guide as well.Mon, Nov 17, 2008 at 10:36 PM #
Shiv on Things Caches Do
Great work…Lucid and informative…Thanks
Mon, Nov 17, 2008 at 09:14 PM #
Alex on Things Caches Do
I really liked the whiteboard-ish sequence diagrams. What tool was used to draw these?
Mon, Nov 17, 2008 at 07:10 PM #
Rick on Things Caches Do
Very helpful! Thanks Ryan.
Mon, Nov 17, 2008 at 06:59 PM #
Ryan Tomayko on Things Caches Do
Ryan: Uggh. Thanks.
Mon, Nov 17, 2008 at 04:44 PM #
Damian Janowski on Things Caches Do
Great writeup. A complex topic made simple.
Mon, Nov 17, 2008 at 03:00 PM #
Ryan on Things Caches Do
Nice writeup!
One minor nitpick, in the Expiration section, the image shows the return of max-age=600, then in the paragraph following you state that the content is valid for 5 minutes. 600 seconds is 10 min.
Mon, Nov 17, 2008 at 12:30 PM #
Abhi on Things Caches Do
Thanks.
Mon, Nov 17, 2008 at 11:19 AM #
Lucas on Things Caches Do
@Abhi: max-age wins over expires. See RFC 2616 section 13.2.4
Mon, Nov 17, 2008 at 10:30 AM #
Ryan Tomayko on Things Caches Do
Abhi: HTTP 1.1 caches are to ignore the Expires header entirely if a max-age Cache-Control directive is present in a response.
Mon, Nov 17, 2008 at 09:45 AM #
Abhi on Things Caches Do
Thanks for the wonderful write up. Have a question though.
If a response has both cache control as well as expires header and the values do not match then which one takes precedence?
Mon, Nov 17, 2008 at 08:41 AM #
jb on How I Explained REST to My Wife
Very helpful and accessible! Thanks!
Sat, Nov 15, 2008 at 04:24 PM #
Greg on Why I'm Pining for PDF Support in Firefox/Gecko
There are solutions for printing to PDF from a webpage…#14 above or by installing PDFCreator and just printing to that PDF printer.
I just installed a firefox extension that allows me to print webpages from the command line…I can choose a printer, pdf or png…‘Command Line Print’. The extension uses Gecko. http://torisugari.googlepages.com/commandlineprint2
This is great, because I created 300+ static webpages that I'd like to print and bind into book form. Now, I can just create a script file instead of navigating to each page to print it.
Fri, Nov 14, 2008 at 03:39 PM #
Anonymous Coward on Got a gun
Indeed.
Wed, Nov 12, 2008 at 02:21 AM #
IsamarC on How I Explained REST to My Wife
Very good explanation of how REST works, Mr. Tomayko. I do wish you had added the context information in the article, perhaps at the beginning, and, in complete agreement with what Andrea said above, that you had used your wife’s name, and an example that had to do with her job as a teacher, rather than to show her as the “little ignorant housewifey” who does nothing but gossip with her sister and mom, clean the house, and “GET” things for you, if not, alas, your jokes.
I did find the sexism so blatant that it was distracting, and definitely detracted from what could have been the best and simplest explanation for it.
Tue, Nov 11, 2008 at 01:39 PM #
NickZA on How I Explained REST to My Wife
Ryan,
This is nice — I will show it to my wife as she is also a teacher (a linguist) and is interested in computers and computer languages. I'm a web programmer myself.
I see why some might think it sexist, but I find that very misguided really — you and wife obviously have a good relationship for her to sit through that, and she must have good self esteem not to feel condescended to or just plain confused when you are discussing very technical aspects of your work with her. Would that everyone could be this way with their partners.
As the band Live would say, “We came to the earth to graze”. No reason not to resist learning.
Tue, Nov 11, 2008 at 11:27 AM #
Hani on How I Explained REST to My Wife
A blessing!I have an essay to write on REST dued in a week and this little “conversation” helped heaps! Thanks Ryan!
Tue, Nov 11, 2008 at 07:33 AM #
Jen on How I Explained REST to My Wife
LMAO! I didn’t find it sexist at all; it just happens to be a technical man explaining to a non-technical woman. I think it was great how he dumbed things down for the layperson to understand. It reminds me of working in the computer labs when I was in college, trying to explain why users' documents didn’t magically save to their floppy disk when the computer went BSOD. :) (Ok, that was before auto-save, but still…)
Thu, Nov 06, 2008 at 03:43 PM #
Bob Aman on Introducing Rack::Cache
+1 to the generic HTTP caching test suite.
Wed, Oct 29, 2008 at 07:46 PM #
Jo on How I Explained REST to My Wife
“Fact is, it’s a very common scenario as described in this post. If the author would have pretended to be a woman explaining it to her non-tech husband, it would only be patronizing, if anything, and you'd have to be naive to buy it.”
Im sorry, but sometimes I think it also happens that a tech girl explains things to her non-tech boyfriend, so I think your comment is the only sexist thing here. If there are not more women in technology is because of guys like u, who make them feel as freak weirdos. The post itself is not sexist, and its amazing: well done!
Wed, Oct 29, 2008 at 12:08 PM #
Robert on Minimal System Backups with rdiff-backup and Yum
Yes where can one install rdiff-backup for centos5 ?
Tue, Oct 28, 2008 at 05:25 AM #
Ryan Tomayko on Introducing Rack::Cache
Yes, I'd very much like to work on a generic HTTP caching test suite. Rack::Cache has a decent set of unit tests but I really wish there was something that was external and operated at the wire protocol level.
Also, I've edited the post to be more clear on the trade-off between Rack::Cache and a high-performance intermediary (s/overhead/infrastructure investment/).
Mon, Oct 27, 2008 at 10:28 AM #
Mark Nottingham on Introducing Rack::Cache
P.S. Want to work on generic HTTP caching test suites?
Mon, Oct 27, 2008 at 01:31 AM #
Mark Nottingham on Introducing Rack::Cache
Ryan,
I totally agree that for most devs getting a cache like Squid up and running is a difficult, unappealing task, for the reasons you state (also, Squid for one isn’t too friendly to typical Web devs, as its core audience is sysadmins and network folk). While we can work on these platforms to make them easier to understand and work with (I've been dipping my toes in here), it’s still a big leap for most.
One of the problems that I've had in getting caching adopted is that by the time people think of it, it’s too late; they've already designed and coded their resources. The fact that it’s hard to get them a cache to work with from the get go only complicates this.
So, making caching easier to integrate into apps from the beginning — by building HTTP caching in to the frameworks — is a fantastic, very smart strategy to make sure that when people need that high-end scalability, they can transition easily, by interposing an intermediary (still one of the great strengths of HTTP IMO).
Thanks for the clarification (I only saw technical overhead, not social/management overhead when I read that), and kudos!
I'm also heartened by the IMS/INM validation support that’s starting to show up; earlier frameworks tended to do the simple thing and just compare a hash of the content after generating it, thereby incurring all of the cost still. Newer ones (including this, AFAICT) are being much smarter and allowing validation to “see” inside of application semantics to shortcut that.
Cheers,
Mon, Oct 27, 2008 at 01:30 AM #
Ryan Tomayko on Introducing Rack::Cache
Hi Mark. I was hoping you would stop by.
Let me clarify: when I said “overhead”, I was speaking specifically about the time and research involved in getting a separate caching daemon up and running and then managing it and not about the machine resource overhead involved. I should have been more clear on this.
As you mentioned, a separate, high performance gateway cache has massive performance and resource use advantages compared to something like Rack::Cache. Unfortunately, I'm afraid the complications involved in scaling these systems down is hurting adoption of more advanced HTTP caching techniques because the benefits are unattainable without the investment (headache) of managing another large piece of infrastructure. So caching becomes an afterthought – something you learn about only after you've made the investment in a high performance gateway cache. Rack::Cache aims to make the benefits of HTTP caching available very early and broadly, even if in a diminished capacity. I suppose its something of a worse is better approach.
I do think the performance improvements created by something like Rack::Cache can be extremely compelling for the types of web applications I've been dealing with for the past few years. A typical Ruby web app performs lots of database reads (often with multiple round trips) and heavy string manipulation. The sophisticated web and ORM frameworks bring large productivity gains and ease maintenance but there’s a lot of extra code to move through and the layers of abstraction often sacrifice performance for simplicity. On top of all that, we're running on one of the slowest interpreters in existence.
What all that adds up to is significant resource (especially CPU and memory) use in generating a full response. I'm finding that, in a great many cases, I can generate cache validators in 1/10th – 1/50th of the time required to generate a full response due to less DB interaction, string operations, and just spending less time in the framework. With something as simple as Rack::Cache, it’s possible to build my app such that my backend never has to generate the same response twice (within resource limits, of course).
None of these arguments support Rack::Cache over a high performance daemon or CDN. But Rack::Cache makes the benefits available in some form for much less cost. And the beautiful thing is that your app has been built with standards from the beginning so moving up to a high performance system should not involve major application-wide changes to your backend codebase. The systems are complimentary.
Also, systems like Rack::Cache might not make sense in other environments. The value of such a system is directly proportional to the average amount of resource use required to generate a full response compared to that required to generate cache validators. A PHP app that performs direct, hand-crafted SQL queries and doesn’t use a template engine might not see the same increases because the difference between generating full responses and validators is negligible. But a Ruby app that uses an ORM and makes tens of thousands of method calls per request is just ripe for massive gains because generating cache validators is significantly less work than generating a full response.
Sun, Oct 26, 2008 at 09:31 PM #
Mark Nottingham on Introducing Rack::Cache
Hey Ryan,
It’s great to have more cache implementations; there are few around, mostly because it’s actually a fairly complex thing to implement well.
However, I was somewhat surprised by your statement “…without the overhead of a separate daemon process.” To me, this is the fundamental limitation of this kind of of approach (whether it be in Python with WSGI or Django, or here in Ruby); concurrency.
Any modern Web proxy/cache implementation is built to be massively concurrent, based upon an event loop. The limited functions of a proxy/cache are actually a huge win in this respect; because they only ever need block on disk access and network access — both things that can be factored out on modern OSs — it’s possible to make assumptions in your architecture and get massive scalability and performance wins.
In contrast, getting good concurrency in a dynamic language takes a tremendous amount of programmer discipline, and even then it’s very difficult to get performance and scalability close to an order of magnitude less* than the approach above. And, of course, if you're running on Apache — as most people will be — you pretty much throw any serious amount of concurrency out of the window.
So, the “the overhead of a separate daemon process” is IMO a mistaken characterisation. In my day job we run a lot of servers this way; dynamic code on the back end, fronted by a Squid process to speed things up. It works — and scales — remarkably well.
By no means do I want to discourage you from taking this route — as I said, it’s great to have more implementations — but realistically, it will never perform as well as a separate Squid, Varnish, etc. OTOH, it will be easier to integrate new features into your cache; we've been doing that progressively in Squid for a while now, because it didn’t meet a lot of our needs, but of course it’s a slow process.
Cheers,
* good concurrency != threads
Sun, Oct 26, 2008 at 07:02 PM #
Josh on How I Explained REST to My Wife
Great explanation. I was at a tech talk about WCF and how it relates to REST and thought, hmmm, what exactly IS REST all about. I googled and found your post, Great.
As far as the comments about sexism, personally I would disregard. If in fact, the conversation happened, well it happened. How is that sexist? I've explained many things to my wife (in laymen’s terms) and she has a CS degree. She’s explained many things to me (in caveman’s terms), and I'm humanoid too. So what gives?
Finally, my wife has sat and listened to me go on and on about something and I don’t think that she is really interested, I think that she simply loves me, and guess what, I love her back for it!
Sun, Oct 26, 2008 at 04:23 PM #
John Labovitz on Introducing Rack::Cache
This is exciting! I've written a micro framework called Gossamer using Rack and memcached. I've been thinking lately of removing the explicit dependency on the cache, possibly by using a front-end cache like squid. But it seems that your Rack::Cache would get me most of the way there, and be more cleanly implemented in Rack — as well as being less of a deployment pain.
Sun, Oct 26, 2008 at 02:47 PM #
Manish on Introducing Rack::Cache
Hey David, how did you create that neat diagram?
Sun, Oct 26, 2008 at 12:56 AM #
Ryan Tomayko on Introducing Rack::Cache
Bob: Absolutely. There’s a TODO list and I'm open to any and all features/bug-fixes that would bring the system further into line with RFC 2616. It’s very much still an experimental project so nothing’s totally out of the question. There should be enough code there to set the tone.
I appreciate changes in the form of links to git repos with discrete commits and good commit messages but I'm also happy to accept patches via email. The easiest thing is probably just to fork me on GitHub.
Sat, Oct 25, 2008 at 08:17 PM #