One suggestion I''ve been thinking about is to make the router into an easily replaceable plug-in, if you will. I can imagine all kinds of reasons to have special purpose and feature routers. Maybe this plug-in idea could be for the whole product. Every core part of Rails would be a plug-in. Rails then would be defined as a structure frame. This would allow a totally distributed and failsafe runtime architecture. It would allow all the core modules to be replaced for any purpose. A site architecture, for example, could be designed using Amazon Web Services virtual servers creating execution nodes on demand with distributed Rails loosely-coupled plug-in parts running and communicating as needed. A Rails site would then be completely dynamically part-wise scalable to any size as needed. It would be swarms of plug-ins working to achieve site goals. Notice a tightly coupled version on a single machine could still be very fast. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Use merb! Just kidding. Componentized does not mean parallelized. Think about it this way. Merb2/Rails3 will be defined as a standard for interaction between components. The relationship between those components however is 1-to-1. Even in the event that Rails becomes mountable (the way merb can be, via slices), there is still a master host app which is incharge of how things run. Parallelizing a web framework is an all together different matter. :) And tbh, that''s sort of how large scale deployments work anyway. You''ve got a set of app servers, a database server (or several if you have something like mysql_proxy set up), and you can increase the number of app servers you need (since they''re interchangeable). Glad to see that people are thinking about the implications of the merge! -Ted On Jan 8, 5:42 pm, johnswolter <johnswol...@gmail.com> wrote:> One suggestion I''ve been thinking about is to make the router into an > easily replaceable plug-in, if you will. I can imagine all kinds of > reasons to have special purpose and feature routers. > > Maybe this plug-in idea could be for the whole product. Every core > part of Rails would be a plug-in. Rails then would be defined as a > structure frame. This would allow a totally distributed and failsafe > runtime architecture. It would allow all the core modules to be > replaced for any purpose. > > A site architecture, for example, could be designed using Amazon Web > Services virtual servers creating execution nodes on demand with > distributed Rails loosely-coupled plug-in parts running and > communicating as needed. A Rails site would then be completely > dynamically part-wise scalable to any size as needed. It would be > swarms of plug-ins working to achieve site goals. > > Notice a tightly coupled version on a single machine could still be > very fast.--~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, Jan 8, 2009 at 4:42 PM, johnswolter <johnswolter@gmail.com> wrote:> > One suggestion I''ve been thinking about is to make the router into an > easily replaceable plug-in, if you will. I can imagine all kinds of > reasons to have special purpose and feature routers.I''d love to hear them. Honestly, I can''t think of any offhand that would trump a flexible enough router. Maybe this plug-in idea could be for the whole product. Every core> part of Rails would be a plug-in. Rails then would be defined as a > structure frame....[snip]> A site architecture, for example, could be designed using Amazon Web > Services virtual servers creating execution nodes on demand with > distributed Rails loosely-coupled plug-in parts running and > communicating as needed.It seems to me that you''re still going to need some sort of communication between those nodes. We already have a means of communication for web apps -- HTTP. And we already have a way to scale Rails on EC2 -- put a load balancer (nginx) in front of it, and let each node run a webserver. I would love to see Rails be more modular, but I''d rather see that at the activesupport level -- for example, I need inflection in a library I''m writing, which is neither Rails nor Merb. My two best choices are activesupport or extlib, both of which include WAY more than I need. Other than that, I suppose I could use Sequel, which is even more stuff I''m not using. Inflection should be its own gem. So should time intervals (5.days.ago). In particular, anything that messes with core Ruby classes, I''d like to be able to use without pulling in everything else that messes with core Ruby classes. But the other stuff in core, like the router... Any router is going to be tightly bound to a controller model, unless it''s something without a controller, like Sinatra. What is gained by making them pluggable? --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Use merb! Just kidding. Componentized does not mean parallelized. Think about it this way. Merb2/Rails3 will be defined as a standard for interaction between components. The relationship between those components however is 1-to-1. Even in the event that Rails becomes mountable (the way merb can be, via slices), there is still a master host app which is incharge of how things run. Parallelizing a web framework is an all together different matter. :) And tbh, that''s sort of how large scale deployments work anyway. You''ve got a set of app servers, a database server (or several if you have something like mysql_proxy set up), and you can increase the number of app servers you need (since they''re interchangeable). Glad to see that people are thinking about the implications of the merge! -Ted On Jan 8, 5:42 pm, johnswolter <johnswol...@gmail.com> wrote:> One suggestion I''ve been thinking about is to make the router into an > easily replaceable plug-in, if you will. I can imagine all kinds of > reasons to have special purpose and feature routers. > > Maybe this plug-in idea could be for the whole product. Every core > part of Rails would be a plug-in. Rails then would be defined as a > structure frame. This would allow a totally distributed and failsafe > runtime architecture. It would allow all the core modules to be > replaced for any purpose. > > A site architecture, for example, could be designed using Amazon Web > Services virtual servers creating execution nodes on demand with > distributed Rails loosely-coupled plug-in parts running and > communicating as needed. A Rails site would then be completely > dynamically part-wise scalable to any size as needed. It would be > swarms of plug-ins working to achieve site goals. > > Notice a tightly coupled version on a single machine could still be > very fast.--~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> Inflection should be its own gem. So should time intervals (5.days.ago). In > particular, anything that messes with core Ruby classes, I''d like to be able > to use without pulling in everything else that messes with core Ruby > classes.This is something that we intend to do, not through seperate gems but through other mechanisms. One of the things we''re hoping to do for rails 2.3 is to make active support ''cherry pickable''. So give you an option like: require ''activesupport/inflector'' And only get the inflection functionality, and nothing unnecessary.> But the other stuff in core, like the router... Any router is going to be > tightly bound to a controller model, unless it''s something without a > controller, like Sinatra. What is gained by making them pluggable?''Modular'' and ''Pluggable'' are a bit like ''scalable'' to developers. We love the words but don''t necessarily know why, or what problems we''d be solving or what changes we''d be making. So I''m always hesitant to promise ''modularity'' or ''pluggability''. Having said that, in cases like the above where you want something, but don''t want some baggage, we can and will make the changes needed to support that. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---