[Mailman-Developers] Architecture for extra profile info

[Terri Oda]

On 13-04-18 8:03 AM, Richard Wackerbarth wrote:
> On Apr 18, 2013, at 1:19 AM, Florian Fuchs <flo.fuchs at gmail.com> wrote:
>
>> 1) It should be self-contained.
>> Meaning: It should not depend on any
>> mailman/mailman.client/postorius/hyperkitty packages.
> Agreed

I agree about not needing postorious/hyperkitty, but I think a case 
could be made that interdependence with mailman core and mailman client 
might make sense.
> I would advocate that this "User" module make it appear as if stores the entire "record" for the user.
> In the implementation, it could actually store parts of the user information in multiple databases (one of which could be the MM-core).
>
> This would also allow the option of having the MM-core become a client of this User module, just as it now relies on an external message store.

Two options occur to me:

1. The user module is what mm-core uses for all user stuff.

I thinks case, case we have to be *much* more conservative about 
dependencies.  I think Django would be right out as a dependency for 
Mailman core, for example.  Plus, we're going to have to care a lot more 
about speed and all.

2. The user module reads from mm-core and augments it.

This gives us the ability to supplement mm-core without impeding speed.  
We discussed possibly filling in the blanks with respect to things like 
the user preferences (which are currently set by membership, by user and 
by email address... but a lot of those return an empty set when queried 
if nothing is set directly there...) so this is maybe something we 
already want.

Conceptually, #1 is probably easier because everything will be in one 
place, but if we do #2 right, we can make it just as conceptually easy 
for HyperKitty/Postorius/etc. without impeding Barry's core dev at all.  
That does mean in case 2 that Mailman Extraneous User Stuff is going to 
depend on Mailman Core, though.

My preference is #2:
a) It doesn't add any dependencies to Mailman core.
b) It doesn't require big changes in Mailman Core.  Given that core is 
pretty much ready to release, now would be a bad time for changes, and 
I'm just not sure we can justify that amount of work for the types of 
features that will be built on the extraneous user stuff.
c) It will be much easier to rip this out and replace it when we better 
understand our actual needs.   (e.g. Right now, I think a case could be 
made that a quick mock-up in django would be fine, but I suspect that 
requiring django for some potential applications would border on ridiculous)

We're probably going to be running around with a bit of a hack job for 
the user database in the near future (either done by a student who needs 
it in a hurry or done by one of the core devs to support a student who 
needs it in a hurry) so while I don't like to design on the assumption 
it's going to go wrong, I think in this case planning for a redesign 
might be prudent because it's pretty clear we don't actually know all 
our requirements.

  Terri