authentication and authorization are the first steps for almost all the web applications. even though there are a few plugins out there I think there should be some official ready to go rails components/generators for this purpose, configurable with a few options, like login :with=>email or name ... and may be
allow: open_id ..,
:have=>control_panel ...

now all "frequently rails application coders" are doing their own ready to go startups with a lot of steps (that they do each time) done like authorization ..

and since authentication and authorization are almost the first and must have codes for almost each application, there will be a better standardization for the rest of the plugins.

We have done many applications with .NET 2 or 3 years ago, and the authentication and authorization were too ready to go that each time I start building a rails application I miss it .

authorization and authentication should be more in conventions.

Thanks and best regards to all friendly Rails people.
Mustafa Ekim

The current Single-Table Inheritance model inherently does not scale well to large and complex class structures, and can prove troublesome to work with when the required structure and functionality of a child-class greatly extends that of a parent class.

Moving data for child-classes into a separate table for each class would allow for far more efficient (i.e. normalised) database structures. Each entry in a child table would also maintain an entry in all parent table(s), allowing us to keep the ease of use we currently experience, since retrieving all data for members of a class, or a specific sub-class, is merely a case of using appropriate joins between tables, and should not require any intervening join-tables.

Error display is amongst the oldest pieces of code in Rails 2.x, it went almost untouched from the old days of Rails 0.x. They insert html and you can barely customize the ouput messages. The code is spread between templates, models and helpers. With the form input helpers the story is similar, they wrap your input (a inline element) around a div (a block element), and if you want to change this, you must have an initializer overwriting a ActionView class variable...

With the new Nested model forms just around the coner I think it is the time to make this improvement.

Right now, after_save and its kin all run inside of the same transaction. While correct in some cases, it is a pain in others. We need another callback that happens after the transaction gets closed. A great example of this is imagine an after_create on object X that calls into an async process to perform a task that pulls some info from object X. There is a race condition right now where if you send the request before the transaction closes, so the other process might not be able to get the new record from the DB since the creation transaction is not done.

Currently... No exact details are available for beginners to start with. Its really confusing whats coming in Rails 3.0 and what will be " Out ". What best features of Merb are planned in Rails 3.0.

Once has to keep track of Merb as well as Rails books, leaving them in confused stage. whats going to finally come up.

It would be a nice way.. to end up maintaining both sites of " Merb " and " Rails " and start with a new fresh site dedicated totally for Rails 3.0.

The existing material can always be included from both this sites, if at all they are going to make it in Rails 3.0

A step in the right direction would help many developers/ students around here.