[Product-Developers] Re: [Plone-Users] Survey of membrane/remember users and stakeholders

[Rob Miller]

Wichert Akkerman wrote:
> Previously Martin Aspeli wrote:
>> Hi Rok,
>>
>>>> I'd like to ditch the Archetypes dependency, at least in membrane
>>>> itself. It makes membrane a less attractive option for many high-volume
>>>> sites, and makes some things very complicated that need not be.
>>>>
>>>> I'd also like to do some more performance work. The membrane catalog,
>>>> for instance, has a lot of indexes that could probably be rationalised
>>>> away, and some of the search-based operations could be made simpler by
>>>> using a direct user id -> user object btree, for example.
>>>>
>>>> I suspect that plone.relations would be a good way to achieve both of
>>>> these things.
>>>>
>>> i dont know how far florian is with paula (this years gsoc project),
>>> but was ment to be replacement for membrane/remember. you should
>>> definetly speak with him about this.
>> The last I heard, Paula was an effort to bring PAU (the Zope 3 
>> equivalent to PAS) to Zope 2. Florian's GSoC project did indeed set out 
>> to make an AT-free membrane, but from what I can tell, that didn't 
>> actually happen.
>>
>> Using PAU in Zope 2 is definitely interesting from an R&D perspective, 
>> but the debate at the time suggested that it's a rather large pill to 
>> swallow, and would introduce some new problems even as it solved some 
>> existing ones.
> 
> In particular PAU is a small subset of (Polone)PAS, which does not
> support many things we do, while having in my opinion somewhat
> unfortunate abstractions in other places from what I remember. I only
> see disadvantages for us. Not everything from Zope 3 is better than what
> Zope 2 has!
> 
> I think it would be much more interesting to see if we can leverage
> repoze.who in Zope 2. I kind of expect that that is very doable,
> and it would make us compatible with a much larger python community.

+1 to this.  there's already a product called whoopass 
(http://pypi.python.org/pypi/Products.whoopass) which is simply a PAS plugin 
that will pull authentication information from repoze.who earlier in the WSGI 
chain.  as Plone moves to shipping w/ a WSGI pipeline out of the box, i think 
this approach is a great idea.

i'll also second what martin said... membrane is just a set of PAS plug-ins, 
pulling user data (auth, properties, groups, roles, whatever) from content. 
it currently assumes that the content in question is AT content, which is due 
simply to a lack of foresight on my part, but it wouldn't be too much work to 
remove these assumptions.

i think membrane and repoze.who can and should coexist nicely together. 
there's no conceptual problem with pulling in auth and some user properties 
from LDAP via repoze.who, and other user properties and workflow from content 
via membrane.

there are some pain points here, however, which will need to be resolved 
before this can be touted as something viable for your typical Plone 
integrator type, someone w/o the time or skill to dig deeply into the guts of 
the user system:

- Plone needs to autogenerate some UI based on the user objects that PAS 
generates.  a lot of folks want to use remember just because they don't want 
to have to tweak their member profile pages for every member schema change. 
this only works when all of the member properties are coming from a single 
piece of content.  we should be able to wire up user properties from any 
arbitrary sources and have simple view and edit screens generated at the 
aggregate level, in front of PAS, instead of forcing this to be behind PAS.

- the PAS search APIs are teh suX0r.  yes, i know that many of the user 
sources might not be able to support sophisticated user enumeration or 
searching.  but the APIs should be rich and able to support sophisticated 
searching, with the weaker plug-ins having the ability to opt-out of 
supporting all the features.  the current situation is that we have extremely 
weak searching APIs, and solutions that provide better support pretty much 
have to route around PAS entirely to expose their functionality.  the ideal 
would be to be able to make calls to the acl_users object which will iterate 
through the search plug-ins, transparently constructing queries against both 
an LDAP server and a member catalog because the searched-upon properties are 
spread across both sources.  this isn't going to happen without major 
improvements.  seriously, the current member searching capabilities are a joke.

that being said, i'm also skeptical of the paula approach.  PAS and PAU are 
meant to solve the same problems.  PAS has a few warts, but it's not so broken 
that it needs to be scrapped.  PAS isn't going away.  adding PAU behind PAS 
sounds like a horrible idea, more of the typical Plone trap of adding more 
layers of complexity w/o actually taking anything away.  if we're going to add 
new points of pluggability, let's at least use repoze.who, which is a) already 
ready already, and b) gaining wide uptake outside of the Zope world.

-r