hooray for clayton and calvin from six feet up!  they've been able to get a 
bunch of work done on remember in support of a client project, and have got us 
within spitting distance of a beta release.

thanks, guys, for all your work.  i've taken a look at the code and have a few 
notes:

http://dev.plone.org/collective/changeset/26308:

* in MemberDataContainer.getAllowedMemberTypes(), you're returning a list of 
all the registered membrane types.  the registered membrane types, however, 
can include objects that are property providers, group providers, role 
providers, etc., in addition to authentication providers.  what we really need 
is to get away from thinking of a member "type" and to start thinking of a 
member "policy", so someone could register and then get the correct set of 
objects created.  at the very least, though, we should be filtering so that 
only auth provider objects are returned, though.

* ultimately, we want to get away from depending on the MemberDataContainer 
altogether.  it would be much better if "defaultType", and any other 
member-related config information we want to store, were managed via a Z3 
schema that can be associated w/ the MembershipTool, exposed via formlib.


http://dev.plone.org/collective/changeset/26290:

* the MemberDataContainer.searchForMembers() method doesn't really belong on 
the MemberDataContainer any longer.  instead, there should be an adapter for 
IMembraneTool that provides a new interface called IMembraneSearch, which can 
expose a searchForMembers method.  the MembershipTool would retrieve the 
MembraneTool and adapt it to IMembraneSearch to actually perform searches.

* the MembershipTool should no longer assume that all member objects live in 
portal_memberdata.  we can introduce a "defaultMemberContainer" config option 
where new member objects will be placed, but addMember should take an optional 
"container" argument as an alternative.  and "deleteMembers" (which should 
ultimately delegate to some member deletion policy) should find the member 
objects by doing catalog searches rather than by assuming the objects live in 
portal_memberdata.


GENERAL:

we need some unit tests, there are only two right now.  i don't expect you to 
cover the entire codebase (and anyway, most of the hard work is done by 
membrane, which has reasonable coverage), but it would be great to get some 
tests on at least what you've worked on, such as a couple for the new 
registration tool, and a few for the member searching and member addition / 
deletion stuff mentioned above.


all in all, though, it's coming very well!  thanks so much for the work you've 
already done!

-r