On Thu, May 21, 2009 at 8:54 AM, Mislav Marohnić
<[email protected]> wrote:
> Here are some ideas for parts of the future public API:
>
> monitoring & profiling: hooks for NewRelic/TuneUp/Scout instrumentation;
We have a 'probes' based summer of code project for exactly this kinda thing.
> ActiveRecord fulltext search & indexing: for Sphinx and other plugins. the
> core implementation, however, would be just using common RDBMS features such
> as "WHERE name LIKE '%foo%'";
I'm not 100% sold that there's something abstractable here. The
semantic and syntactic differences are much more drastically different
between sphinx, solr, mysql fulltext and tsearch2 than between
postgresql and mysql's INSERT or SELECT statements.
> authentication & authorization: for restful_authentication, authlogic, etc.;
This is something I'm *strongly* opposed to including in the core of
rails until we have an absolutely bullet proof and popular solution
from various plugins. yehuda and carl have spoken about porting the
general design of merb-auth into something for rails 3, and we can
probably start there.
> testing API & helpers: so that rspec-rails, webrat and other integrations
> wouldn't break between releases.
You can see the start of this for integration and functional testing
with the (planned) move to rack-test for the implementation. That
should give everyone a common block on which to build.
> Here are some current examples of what I consider a public API of Rails:
> ActionController::Base.param_parsers[Mime::XML] = Proc.new { |data| ... }
> ActionView::Template.register_template_handler('foo', FooHandler)
> I18n.backend = MyBackend.new
> All of these are used to inject features into the framework by implementing
> some interface, not monkeypatching. This is good.
Right, to say we don't have an extension API is pure FUD, what we do
have is a TINY extension API that needs to get bigger. The way it'll
get bigger is for people who maintain plugins to suggest what APIs
they'll need, and help us get them included and stabilised.
The alternative is for us to invent extension points from our ivory
tower (or rimu single story home). The odds of us getting it 'mostly
right' are pretty good, but with feedback from plugin authors we'll
probably get it completely right.
> What really saddens me is that now all focus is turned towards middleware
> and that they've become almost the preferred way to inject features into the
> framework. Tons of Rails features were already extracted. The whole stack,
> including the main app, is then synchronized through a single object: "env".
> Is the public API going to become string keys on a big fat hash object?
There are a few cases where we've probably gone overboard (I'm still
not sold on the exceptions changes) however we can always suck them
back in before we cut a 3.0 release. However at a fundamental level
if we can provide useful middlewares for sinatra, ramaze and other
guys to use, why not?
--
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
