[Zope-CMF] Re: Re: RFC: PAS and the (non?) future of members

Rob Miller ra at burningman.com
Thu Feb 2 19:31:43 EST 2006

On Thu, 02 Feb 2006 23:33:49 +0000, Jens Vagelpohl wrote:
> On 2 Feb 2006, at 23:01, Rob Miller wrote:
>> On Thu, 02 Feb 2006 18:14:15 +0000, Jens Vagelpohl wrote:
>>> It does sound interesting, unless the user folder all of a sudden gets
>>> overloaded with all kinds of APIs that it doesn't need for normal Zope
>>> operation.
>> i don't understand what you mean by overloading the user folder w/ "all
>> kinds of APIs".  i'm not proposing any additions to the user folder at
>> all. i'm talking about a custom user class, along w/ custom user
>> factory, authentication, and user property decoration plugins that move
>> the behaviour that is currently in the member object down into the user
>> object.  no additional features, less complexity, more flexibility.
> I mean sticking Plone-only stuff onto something that's a simple user
> folder and should be completely agnostic of how it is used.

oh, i see.  did i imply that Plone-only behaviour should be dropped
into the CMF?  i'm not detecting some prejudice that might possibly be
causing certain readers to jump to conclusions about my proposal, am i?  ;-)

of course i don't want to put Plone-specific code into the CMF.  i'm
talking about PAS (i.e. PluggableAuthService... see
http://www.zope.org/Members/urbanape/PluggableAuthService) and
a set of custom plug-ins that migrate the existing CMF member behaviour
down into a standard Zope user folder implementation.  nothing
Plone-specific at all.

Membrane, to which i referred, _is_ Plone-specific.  but i'm not implying
that it be used in the CMF, just that there are some good ideas being
expressed there, that are worth considering in a CMF-only context.


p.s. i've written a blog entry on Membrane
it's intended for Plone developers and is quite Plone-centric, but
provides a high-level overview of the approach i'm talking about.

More information about the Zope-CMF mailing list