"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

In article
[email protected], billkatz-
[email protected] 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.

In article [email protected], jay-news-
[email protected] 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.

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

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.

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. ()
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, Jay L. [email protected] 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.

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 Nov 11, 2005, at 2:30 PM, Pat M. 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.

On 11/11/05, Deirdre Saoirse M. [email protected] 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

On Nov 11, 2005, at 2:30 PM, Pat M. 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.

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. ()
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 M. [email protected] 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

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.

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 Nov 11, 2005, at 1:01 PM, Bill K. 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.

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