On Fri, Jul 24, 2009 at 8:18 PM, Hongli Lai<hon...@phusion.nl> wrote: > > On Jul 24, 10:16 am, Hongli Lai <hon...@phusion.nl> wrote: >> You are right, it doesn't work at this time. But I can make it work. > > With this I mean that Phusion Passenger vendors Rack as well in order > to work around broken applications. With a few tricks I can remove > this vendoring while still retaining compatibility.
Personally I don't mind Phusion Passenger depending on or vendoring in Rack, as long as all the Ruby HTTP servers work the same way (perhaps too difficult a thing to ask). Mongrel doesn't depend on Rack, so ActionPack does. That sort of puts the ball in Rails' court, and accordingly makes it seem to me like we must freeze in Rack when we freeze in Rails (since the whole point of freezing in is that you don't need to deploy anything else to make the app work - aside from the HTTP server you're using, the mongrel gem in this example). But, that currently doesn't really match Passenger, as you say. So, I wonder if someone could make just as strong a case that Mongrel should be changed to depend on Rack and ActionPack should not. Thoughts? Perhaps we need to assess which is more likely to lead to problems with people deploying apps (which are not necessarily running latest release of Rails). In other words, what's more likely to make breaking changes that can't or won't be worked around - changes to the API between HTTP server and Rack, or between Rack and Rails? Looking at the number of commits Joshua had to make to keep Rails up-to-date with Rack, I would have guessed the latter, in which case yeah I'd still vote that we should vendor in Rack. People are more likely to be able to upgrade Passenger, than they are to be able to upgrade to the latest release of Rails just for updated Rack compatibility. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
