> The reason the focus was taken off the login/user engines is because I > felt that it was important to distinguish between > > a) using the engines plugin as a tool for more powerful reuse in your > own development > > and > > b) providing a set of drop in components.
The point is that the engines-plugin is much less usefull without the availability of drop in components. > The former is the more correct, and the latter what inspires all the > negative attention that engines recieve. This does not in any way > prohibit other people from speaking about or promoting any of those > specific engines; just that I no longer have the time or energy to > fight the uphill struggle against thought-followers who believe that > engines are *just* the login/user engines, are high level components, > are evil, and so on. The anti-engines arguments are just plain stupid, because they assume that everyone is smart enough to, or has time to implement yet another perfect user-system. Especially the Login-engine just works, and extendability is neat as it is. And sometimes worse is just better (as Chad Fowler said in a presentation in Delft lately). If code-reuse is usefull between your own projects then it most likely is also between projects of different people. Sharing code is the core of Open Source, and Engines allow this in a neat, aspect-oriented way. It just must be clear that engines are to be opiniated and have convention over configuration, just like Rails itself. Note also that Engines are a great resource for Rails-Noobs to learn from, to borrow code from, or to get started with. > Regarding login or user engines, at the moment, I'm not very happy > with them because they represent old code (much of which I didn't > even write) which isn't as nice to use as I might like. Others are > already on the case here (search this list for 'hark', for instance, > and of course there is ActiveRBAC). I'd much prefer it if I personally > could focus on the development of the engines plugin, and leave the > actual engine implementations to others in the community. What do you > think? I think that rails-engines.org could be a lot more usefull, and gain a lot more positive attention if it also listed available engines. Now I am not saying that it should immediately become the freshmeat.net for rails engines, but a simple list, as there was on the old site, would already be much better. > Also, with the upcoming release of Rails 1.2, the distinction between > engines and plugins will hopefully basically disappear. Now that I > have an 'official' mechanism to control the order that plugins are > loaded, there's no need for Engines.start, and all the features that > the engines plugin provides can be made available to any plugin that > needs them. This might result an erosion of meaning for the word > 'engine' as applied to any particular chunk of shareable code - we'd > just have plugins that make use of engine-plugin features. The > 'pluginaweek' guys have the right idea - to an extent at least. I > still feel that every 'feature' that the engines plugin provides makes > sense as a coherent, single package, and they got a few things quite > wrong in their recent criticism - see my reply on rails-engines.org if > you're interested. I already read that blog-post, and your reply yesterday. I agree that the engines-plugin offers a coherent set of features, but I think that now with plugins being able to do most things engines do, the idea of engines becomes even more important than the engines-plugin itself. Making rails-engines.org less defensive in its tone, and making it a place where people can find engines too, seems a good step to me. Wybo > As for activity on the lists, well - that's up to you guys! > > - James _______________________________________________ engine-users mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
