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
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
