Rails - Nov 2005 - "Components", loosely coupled plug-ins, and standard logins

After seeing the debate on Rails Engines and periodic calls for a more
unified approach to logins, I thought we could have a healthy thread on how
to collaborate at levels beyond the Rails core.

DHH weighs in:
http://weblog.rubyonrails.org/articles/2005/11/11/why-engines-and-components-are-not-evil-but-distracting
http://www.loudthinking.com/arc/000335.html

I wonder whether our use of language is pushing the debate in less
productive directions. Instead of focusing on the pros and cons of
high-level "components", shouldn''t we be figuring out how to
create
conventions that foster decoupling across plug-ins while still allowing
unified access to relatively standard web data, like login ID, first/last
name, and whether a session is a visitor, member, or some sort of admin?

A plug-in could say it needs access to a login (however that''s
implemented),
and the Rails community has a convention (overridable at the DSL level) that
logins have a loginID and some timestamps. Likewise, a component might need
to address the user, "Hi Bill", and therefore needs access to a
profile
(however that''s implemented), and the Rails community has a convention
that
profiles provide first names, last names, web addresses, etc.

A while ago, I tried to bolt the phpBB message board system onto a
pre-existing website. Yes, I could have said "less is more" and built
just
what I needed from scratch, but there''s value in quickly adding
functions,
just like scaffolding. And there''s value in recognizing what''s
a commodity
function -- one that''s used by many different websites and really
isn''t
domain-specific -- and what''s very central to the value of my web app.
Generic logins and forgotten password handling are commodity operations.
Just like Rails takes care of significant grunt work, I''d like to not
build
my own login handler if a public one fits. There''s also value in
standardizing on a commodity because it stress tests the component: someone
hacking the shared login handler will be detected and solved more quickly.

Message boards can be a commodity as well. Integrating phpBB is not easy
because phpBB has its own user management system. Many portal + phpBB
solutions either adopt the phpBB user system or provide glue between two
separate user systems. Wouldn''t it be nice to have conventions for
decoupling this dependence between bulletin board handling and user
handling, and in general, letting plug-ins know about common resources
without bundling in their own DB schema?

DHH says "if you have a great idea for an engine, or a high-level component
in general, think about this: Is there a way I could abstract a smaller
slice of functionality as an independent plugin and then release that
alongside a pattern that described how to use it like the component would
have done all in software?"

For message boards, you could implement a plug-in that handles posts and
threads. This plug-in would still need to know simple things like the "user
ID" and name of the poster, whether the poster has a home page URL, etc. If
we can agree on how to make such queries without hardwired schemas, we can
promote decoupling and have threads work with a variety of user systems.

Would the first step be creating a beautiful DSL for logins, user
information, and maybe even roles?

-Bill


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On Nov 11, 2005, at 1:01 PM, Bill Katz wrote:
> I wonder whether our use of language is pushing the debate in less  
> productive directions. Instead of focusing on the pros and cons of  
> high-level "components", shouldn''t we be figuring out
how to create
> conventions that foster decoupling across plug-ins while still  
> allowing unified access to relatively standard web data, like login  
> ID, first/last name, and whether a session is a visitor, member, or  
> some sort of admin?
This paragraph made me break out in hives.

Suffice to say that it''s exactly about the antithesis of why I heart  
Rails.

Besides, it sounds more like a job for ISO.

-- 
_Deirdre                                             http://deirdre.net

Exactly what do you like about Rails and why do you think conventions are
the antithesis of that?

We''ve got conventions for automatic STI using a
''type'' field. We''ve got
conventions for how table names relate to model names, and how defaults are
used for association declarations. As far as I know, none of those are
regulated by ISO.

And in keeping with the general Ruby way, I think we should have less of an
edge in remarks.

On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org>
wrote:
>
> On Nov 11, 2005, at 1:01 PM, Bill Katz wrote:
>
> > I wonder whether our use of language is pushing the debate in less
> > productive directions. Instead of focusing on the pros and cons of
> > high-level "components", shouldn''t we be figuring
out how to create
> > conventions that foster decoupling across plug-ins while still
> > allowing unified access to relatively standard web data, like login
> > ID, first/last name, and whether a session is a visitor, member, or
> > some sort of admin?
>
> This paragraph made me break out in hives.
>
> Suffice to say that it''s exactly about the antithesis of why I
heart
> Rails.
>
> Besides, it sounds more like a job for ISO.
>
>

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

What I like about Rails: agility.

I don''t think conventions are the antithesis of rails, I just think  
that "conventions that foster decoupling across plug-ins while still  
allowing unified access to relatively standard web data" is. For  
example, calling something username or login or whatever. Does there  
really need to be One True Way? Who gets to decide?

Edge?

I broke out in hives. Really.
(Too much prior trauma on taxonomy committees, methinks)

I don''t think there''s one true taxonomy. I say this as someone
who
is, like yourself, a writer, and therefore quite aware of the power  
of words. Therefore, I''m somewhat surprised that you think that there  
may be One True Taxonomy.

On Nov 11, 2005, at 1:43 PM, Bill Katz wrote:
> Exactly what do you like about Rails and why do you think  
> conventions are the antithesis of that?
>
> We''ve got conventions for automatic STI using a
''type'' field. We''ve
> got conventions for how table names relate to model names, and how  
> defaults are used for association declarations. As far as I know,  
> none of those are regulated by ISO.
>
> And in keeping with the general Ruby way, I think we should have  
> less of an edge in remarks.
>
> On 11/11/05, Deirdre Saoirse Moen <
deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org> wrote:On
> Nov 11, 2005, at 1:01 PM, Bill Katz wrote:
>
> > I wonder whether our use of language is pushing the debate in less
> > productive directions. Instead of focusing on the pros and cons of
> > high-level "components", shouldn''t we be figuring
out how to create
> > conventions that foster decoupling across plug-ins while still
> > allowing unified access to relatively standard web data, like login
> > ID, first/last name, and whether a session is a visitor, member, or
> > some sort of admin?
>
> This paragraph made me break out in hives.
>
> Suffice to say that it''s exactly about the antithesis of why I
heart
> Rails.
>
> Besides, it sounds more like a job for ISO.
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
-- 
_Deirdre                                             http://deirdre.net

On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org>
wrote:
> What I like about Rails: agility.
>
> I don''t think conventions are the antithesis of rails, I just
think
> that "conventions that foster decoupling across plug-ins while still
> allowing unified access to relatively standard web data" is. For
> example, calling something username or login or whatever. Does there
> really need to be One True Way? Who gets to decide?
I don''t think there needs to be a one true way.  Here''s the
process I
think should happen (using an authentication system, for example)
1. A few people collaborate to come up with a general interface for
authentication
2. They create a new wiki page with these guidelines
3. People write implementations however they want, conforming to the interface
4. End users (developers using the authentication) choose whether they
want to use one of these implementations or not.

It''s not really that big of a deal.  This doesn''t (and
shouldn''t) make
it into Rails Core or anything like that.  However there''s nothing
wrong with a few people saying they''d like to follow certain
conventions so that it''s easy to plug components together.

I want to stress that this would not be a mandated thing at all. 
There could be 10 different convention sets for all I care.  People
will use whichever ones fit their needs...but there''s nothing wrong
with groups of people specifying which conventions they''d like to use
in order to help write more portable, reusable code.

Pat

The funny thing is your argument reminds me of the attacks on Rails. One
True Way? Who gets to decide?

Rails is opionated software. DHH was the man who decided the "golden
path"
but there are ways of overriding his conventions. It''s just easier on
the
golden path.

If a bunch of us get together and decide that a separate Login model is only
for login data and has accessors for loginID, you are free not to follow
this convention. Some plug-ins might be created that assume separated Login,
Profile, and Member models, perhaps with overriding class names and table
names, but they''ll use the convention and be easier to apply to web
apps
that also follow the convention.

I''m not proposing One True Taxonomy any more than DHH proposed One True
Web
Framework. (<cough>)
I *am* proposing that we agree on some basic ideas dealing with user logins,
profiles, and maybe authorization, and that we use a common DSL to describe
it. Agreeing at the DSL level, though, doesn''t prevent you from
substantially changing how it plugs into your specific implementation.

Also, if you mainly like the agility of Rails, you should like the ability
to drop in commodity functions, regardless of how "high-level" they
might
be. There are good reasons to build from the ground up, but those reasons
can involve business decisions.

On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org>
wrote:
>
> What I like about Rails: agility.
>
> I don''t think conventions are the antithesis of rails, I just
think
> that "conventions that foster decoupling across plug-ins while still
> allowing unified access to relatively standard web data" is. For
> example, calling something username or login or whatever. Does there
> really need to be One True Way? Who gets to decide?
>
> Edge?
>
> I broke out in hives. Really.
> (Too much prior trauma on taxonomy committees, methinks)
>
> I don''t think there''s one true taxonomy. I say this as
someone who
> is, like yourself, a writer, and therefore quite aware of the power
> of words. Therefore, I''m somewhat surprised that you think that
there
> may be One True Taxonomy.
>
>

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On Nov 11, 2005, at 2:30 PM, Pat Maddox wrote:
> I want to stress that this would not be a mandated thing at all.
> There could be 10 different convention sets for all I care.  People
> will use whichever ones fit their needs...but there''s nothing
wrong
> with groups of people specifying which conventions they''d like to
use
> in order to help write more portable, reusable code.
I''m all for documenting which conventions one is using.

-- 
_Deirdre                                             http://deirdre.net

In article 
<59aa95140511111301x31b09f07o7f367a7d85a3754a-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>,
billkatz-
Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org
says...
> DHH says "if you have a great idea for an engine, or a high-level
component
> in general, think about this: Is there a way I could abstract a smaller
> slice of functionality as an independent plugin and then release that
> alongside a pattern that described how to use it like the component would
> have done all in software?"
> 
> For message boards, you could implement a plug-in that handles posts and
> threads. 
Yes, you could - but why?  I don''t want a plugin that handles posts and
threads.  I want a message board.  I don''t want to have to write 
scaffold code around the plugin because the plugin was afraid to get too 
big for its object-oriented britches.  I want to drop it in and go.

Yes, I could write it myself.  I can also write my own disk I/O code, 
but I use databases.  I could write my own web server, but I use Apache.  
Heck, I could simply follow DHH''s coding patterns, but instead, I use 
his framework!  Why is reuse bad, IF it isn''t constraining?

There''s also a big usability boost from reusable components.  Many
users
have seen the vBulletin and phpBB interface before, and they know its 
quirks.  Personally, I''ve got Greasemonkey scripts that automatically 
make my phpBB experience a lot nicer, and that type of customization is 
only growing.  If somebody implements a message board just because they 
*can*, I don''t get to leverage that at all.  Am I the only one here who
hates posting to sites like sourceforge, because the forum interface 
(although perfectly sensible) isn''t familiar?

Anyway, If I *did* write everything myself that I *could*, instead of 
reusing components, I''d never get anything done, and I''d still
be in
assembler - with my own compiler, of course.  I''d rather have a 
slightly-ill-fitting message board than none at all.


-- 
Jay Levitt                | 
Wellesley, MA             | I feel calm.  I feel ready.  I can only
Faster: jay at jay dot fm | conclude that''s because I don''t
have a
http://www.jay.fm         | full grasp of the situation. - Mark Adler

In article
<MPG.1ddf0050994744729896f6-2AO0Uh8ossnZ+VzJOa5vwg@public.gmane.org>,
jay-news-
WxwZQdyI2t0-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org
says...
> 
> Yes, I could write it myself.  I can also write my own disk I/O code, 
> but I use databases.  I could write my own web server, but I use Apache.  
> Heck, I could simply follow DHH''s coding patterns, but instead, I
use
> his framework!  Why is reuse bad, IF it isn''t constraining?
Bad form to reply to myself, but I just realized the extension of this 
argument.  And yes, I know I''m exaggerating, but bear with me:

DHH is exactly the wrong person to look to for guidance on reuse, 
precisely *because* of who he is.  He *didn''t* reuse any of the
existing
frameworks; he went and wrote Rails!  He didn''t even reuse his own 
Instiki; he went and wrote I2.  His refusal to reuse things that don''t 
quite fit is what brought us innovative solutions like Rails - but if we 
all followed his example, we wouldn''t be using it.

-- 
Jay Levitt                | 
Wellesley, MA             | I feel calm.  I feel ready.  I can only
Faster: jay at jay dot fm | conclude that''s because I don''t
have a
http://www.jay.fm         | full grasp of the situation. - Mark Adler

On 11/11/05, Jay Levitt <jay-news-WxwZQdyI2t0@public.gmane.org>
wrote:
>
> > For message boards, you could implement a plug-in that handles posts
and
> > threads.
>
> Yes, you could - but why? I don''t want a plugin that handles posts
and
> threads. I want a message board. I don''t want to have to write
> scaffold code around the plugin because the plugin was afraid to get too
> big for its object-oriented britches. I want to drop it in and go.

I don''t disagree with you, but there are different ways of dropping in
a
message board. You could drop in an entire monolithic message board, or you
could drop in smaller slices of function that allow reuse for more than just
the message board. For example, you might want to use the posts/thread
function or commenting in other areas of your web site.

Shared components also make a lot of sense for administrative functions,
like log analysis. The question is how to best keep these plug-ins isolated
for updating while still permitting access to common models. It''d be
great
to get further discussion on this issue.


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

>  Shared components also make a lot of sense for administrative functions,
> like log analysis. The question is how to best keep these plug-ins isolated
> for updating while still permitting access to common models. It''d
be great
> to get further discussion on this issue.
Maybe they could use the same conventions for everything.  Provide a
generator for the initial model stub, and acts_as_* macros for
functionality.

This is the approach I''m taking with my acts_as_authenticated plugin.
I provide a macro for the controller as well. 
uses_form_authentication adds login/signup/logout/activate controller
actions.

--
rick
http://techno-weenie.net

If a group of people want to work together investigating possible
commonly used features needed by the components of ''abstract''
(i.e.
theoretical, algorithmic, process-flow, NOT code) login systems, why
shouldn''t they? It''s not a quest for the One True Taxonomy. It
might
be a quest for A Good Taxonomy. There''s a subtle difference.

Noone is forcing this one anyone. If you are interested in the notion
of ''design patterns of authentication'' (as explicitly
requested by DHH
on the Rails weblog, btw) then please contribute. But questioning
whether or not such a debate should even happen is just a waste of
time. It''s clearly happening already.

Perhaps something will come of talking about authentication issues.
Maybe we''ll even see some code that might inspire other people to
produce better systems themselves. Maybe we''ll see nothing and
everyone will have wasted their time. But lets see where it goes
first, before trying to establish what the outcome can or cannot be.

- james

On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org>
wrote:
> What I like about Rails: agility.
>
> I don''t think conventions are the antithesis of rails, I just
think
> that "conventions that foster decoupling across plug-ins while still
> allowing unified access to relatively standard web data" is. For
> example, calling something username or login or whatever. Does there
> really need to be One True Way? Who gets to decide?
>
> Edge?
>
> I broke out in hives. Really.
> (Too much prior trauma on taxonomy committees, methinks)
>
> I don''t think there''s one true taxonomy. I say this as
someone who
> is, like yourself, a writer, and therefore quite aware of the power
> of words. Therefore, I''m somewhat surprised that you think that
there
> may be One True Taxonomy.
>
> On Nov 11, 2005, at 1:43 PM, Bill Katz wrote:
>
> > Exactly what do you like about Rails and why do you think
> > conventions are the antithesis of that?
> >
> > We''ve got conventions for automatic STI using a
''type'' field. We''ve
> > got conventions for how table names relate to model names, and how
> > defaults are used for association declarations. As far as I know,
> > none of those are regulated by ISO.
> >
> > And in keeping with the general Ruby way, I think we should have
> > less of an edge in remarks.
> >
> > On 11/11/05, Deirdre Saoirse Moen <
deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org> wrote:On
> > Nov 11, 2005, at 1:01 PM, Bill Katz wrote:
> >
> > > I wonder whether our use of language is pushing the debate in
less
> > > productive directions. Instead of focusing on the pros and cons
of
> > > high-level "components", shouldn''t we be
figuring out how to create
> > > conventions that foster decoupling across plug-ins while still
> > > allowing unified access to relatively standard web data, like
login
> > > ID, first/last name, and whether a session is a visitor, member,
or
> > > some sort of admin?
> >
> > This paragraph made me break out in hives.
> >
> > Suffice to say that it''s exactly about the antithesis of why
I heart
> > Rails.
> >
> > Besides, it sounds more like a job for ISO.
> >
> >
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
>
> --
> _Deirdre                                             http://deirdre.net
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Exactly what do you like about Rails and why do you think conventions 
are
the antithesis of that?

We''ve got conventions for automatic STI using a
''type'' field. We''ve got
conventions for how table names relate to model names, and how defaults 
are
used for association declarations. As far as I know, none of those are
regulated by ISO.

And in keeping with the general Ruby way, I think we should have less of 
an
edge in remarks.

What I like about Rails: agility.

I don''t think conventions are the antithesis of rails, I just think
that "conventions that foster decoupling across plug-ins while still
allowing unified access to relatively standard web data" is. For
example, calling something username or login or whatever. Does there
really need to be One True Way? Who gets to decide?

Edge?

I broke out in hives. Really.
(Too much prior trauma on taxonomy committees, methinks)

I don''t think there''s one true taxonomy. I say this as someone
who
is, like yourself, a writer, and therefore quite aware of the power
of words. Therefore, I''m somewhat surprised that you think that there
may be One True Taxonomy.

On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org>
wrote:
> What I like about Rails: agility.
>
> I don''t think conventions are the antithesis of rails, I just
think
> that "conventions that foster decoupling across plug-ins while still
> allowing unified access to relatively standard web data" is. For
> example, calling something username or login or whatever. Does there
> really need to be One True Way? Who gets to decide?
I don''t think there needs to be a one true way.  Here''s the
process I
think should happen (using an authentication system, for example)
1. A few people collaborate to come up with a general interface for
authentication
2. They create a new wiki page with these guidelines
3. People write implementations however they want, conforming to the 
interface
4. End users (developers using the authentication) choose whether they
want to use one of these implementations or not.

It''s not really that big of a deal.  This doesn''t (and
shouldn''t) make
it into Rails Core or anything like that.  However there''s nothing
wrong with a few people saying they''d like to follow certain
conventions so that it''s easy to plug components together.

I want to stress that this would not be a mandated thing at all.
There could be 10 different convention sets for all I care.  People
will use whichever ones fit their needs...but there''s nothing wrong
with groups of people specifying which conventions they''d like to use
in order to help write more portable, reusable code.

Pat

The funny thing is your argument reminds me of the attacks on Rails. One
True Way? Who gets to decide?

Rails is opionated software. DHH was the man who decided the "golden 
path"
but there are ways of overriding his conventions. It''s just easier on 
the
golden path.

If a bunch of us get together and decide that a separate Login model is 
only
for login data and has accessors for loginID, you are free not to follow
this convention. Some plug-ins might be created that assume separated 
Login,
Profile, and Member models, perhaps with overriding class names and 
table
names, but they''ll use the convention and be easier to apply to web
apps
that also follow the convention.

I''m not proposing One True Taxonomy any more than DHH proposed One True
Web
Framework. (<cough>)
I *am* proposing that we agree on some basic ideas dealing with user 
logins,
profiles, and maybe authorization, and that we use a common DSL to 
describe
it. Agreeing at the DSL level, though, doesn''t prevent you from
substantially changing how it plugs into your specific implementation.

Also, if you mainly like the agility of Rails, you should like the 
ability
to drop in commodity functions, regardless of how "high-level" they 
might
be. There are good reasons to build from the ground up, but those 
reasons
can involve business decisions.

On Nov 11, 2005, at 2:30 PM, Pat Maddox wrote:
> I want to stress that this would not be a mandated thing at all.
> There could be 10 different convention sets for all I care.  People
> will use whichever ones fit their needs...but there''s nothing
wrong
> with groups of people specifying which conventions they''d like to
use
> in order to help write more portable, reusable code.
I''m all for documenting which conventions one is using.

If a group of people want to work together investigating possible
commonly used features needed by the components of ''abstract''
(i.e.
theoretical, algorithmic, process-flow, NOT code) login systems, why
shouldn''t they? It''s not a quest for the One True Taxonomy. It
might
be a quest for A Good Taxonomy. There''s a subtle difference.

Noone is forcing this one anyone. If you are interested in the notion
of ''design patterns of authentication'' (as explicitly
requested by DHH
on the Rails weblog, btw) then please contribute. But questioning
whether or not such a debate should even happen is just a waste of
time. It''s clearly happening already.

Perhaps something will come of talking about authentication issues.
Maybe we''ll even see some code that might inspire other people to
produce better systems themselves. Maybe we''ll see nothing and
everyone will have wasted their time. But lets see where it goes
first, before trying to establish what the outcome can or cannot be.

- james

Exactly what do you like about Rails and why do you think conventions
are
the antithesis of that?

We''ve got conventions for automatic STI using a
''type'' field. We''ve got
conventions for how table names relate to model names, and how defaults
are
used for association declarations. As far as I know, none of those are
regulated by ISO.

And in keeping with the general Ruby way, I think we should have less of
an
edge in remarks.