Re: What happened?

What happened ?

To this list ? To engines ?

Also on rails-engines.org I now already for a few months saw no
direct link anymore to the user-engine, and such. Now I know those
‘demo-engines’ were less than perfect, but I think they are perfect
for experimental web-apps, that for now just needed an user-system,
that can be replaced once the app’s core functionaliry is live.

It’s similar to not worrying about code optimizations and scaling
untill they start to matter.

Also I think engines are in sync with the OpenSource philosophy of
small tools that do well what they do. And their current non-perfect
state is also not against release early and often.

(also see: http://en.logilogi.org/MetaLogi/TheWebCanBeOpenSource)

So please be proud about engines again, and show it on the site!

Wybo

On 11/14/06, Wybo W. [email protected] wrote:

What happened ?

To this list ? To engines ?

Yes, I also have the same concern.

rails-engines is used by active_rbac, which in turn is used by me.
activeRbac is a very nice engine BTW.


Hendy I.
Web: http://hendy.gauldong.net
Mobile: +62 856 24889899
Yahoo Messenger: ceefour666

On 11/14/06, Hendy I. [email protected] wrote:

On 11/14/06, Wybo W. [email protected] wrote:

What happened ?

To this list ? To engines ?

Unless I missed the memo, nothing’s happened to either this list, or
to the engines plugin - they’re both still here, still working, right?
:slight_smile:

The website was re-worked because it suffered heavily from wiki spam,
to the point where it was essentially un-usable as a source of
documentation.

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 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.

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?

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.

As for activity on the lists, well - that’s up to you guys!

  • James

On 11/14/06, James A. [email protected] wrote:

a) using the engines plugin as a tool for more powerful reuse in your
own development

yes this is what I think the best way

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 totally agree. If engines can work with other ‘hack’ plugins, such
as MasterView & theme_support, it’d be great.

Is there such thing as engine_image_tag ?

‘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’m somewhat on your “side”. I see it’s quite ‘weird’ that I have to
install several different plugins just to have the ability of
rails-engine. If only Rails core guys accept this kind of proposal
into standard Rails distro, we wouldn’t have such different projects
aiming at the same thing…


Hendy I.
Web: http://hendy.gauldong.net
Mobile: +62 856 24889899
Yahoo Messenger: ceefour666

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 F. 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.

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

On 11/14/06, James A. [email protected] wrote:

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 is a great idea!

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.

What exactly is happening in Rails 1.2. Are Rails’ plugins essentially
evolving into full functioning engines?

Thanks,
Peter

On 11/15/06, Wybo W. [email protected] wrote:

Also see this blog-post by David, about not to bend too far for
criticism: http://www.loudthinking.com/arc/000600.html

Yup, definitely :slight_smile:

And if you don’t want the LoginEngine (& maybe UserEngine), then plz
turn them into orphanaged RubyForge projects, so others can pick them
up if they want to improve them…

That’s an interesting idea, Wybo. What does everyone else think about
this?

On 11/15/06, James A. [email protected] wrote:

And if you don’t want the LoginEngine (& maybe UserEngine), then plz
turn them into orphanaged RubyForge projects, so others can pick them
up if they want to improve them…

That’s an interesting idea, Wybo. What does everyone else think about this?

I have to agree. I personally wish that James A. will be my Rails
Engines engine (I mean, plugin) hero, not the do-it-all handyman who
spawns every possible use of engine at his disposal. LoginEngine &
UserEngine may be good for… (forgive me) “demo” of Engines’
capabilities, but “real” tasks should be left to individual developers
so e.g. ActiveRBAC can live a happy life.

If you somehow “bundle” (even if just virtually, by putting your
engines in your site, although not directly inside engines plugin
distribution) your own Engines, they seem like they’re “official”
engines, and other engines that serve the same purpose is
“inferioriated”.

I take it you don’t want to be the next Microsoft but in the Rails
world :slight_smile: (Windows Media Player, MSIE, Movie Maker, … aren’t they
“engines”?)


Hendy I.
Web: http://hendy.gauldong.net
Mobile: +62 856 24889899
Yahoo Messenger: ceefour666

Also see this blog-post by David, about not to bend too far for
criticism: http://www.loudthinking.com/arc/000600.html

And if you don’t want the LoginEngine (& maybe UserEngine), then plz
turn them into orphanaged RubyForge projects, so others can pick them
up if they want to improve them…

Wybo

::student:

::Free Software and Open Source Developer:

  • http://www.LogiLogi.org, innovative system for cumulative, shared
    commenting,
    publication and idea sharing: Web as it
    should be…
  • ComLinToo, a computational linguistics toolset written in Perl
  • Lake (LogiLogi.org Make), a make-replacement using makefiles in pure
    C++

::Being: