[Mailman-Developers] Architecture for extra profile info

[Barry Warsaw]

On Apr 18, 2013, at 10:26 AM, Terri Oda wrote:

>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.

Definitely.  However (and I'm not saying it has to be this way ;) if the user
database were a Django app, and there were REST APIs that the core could call
to do updates, then when something in the core changes, an event would get
triggered that would make the RESTish call to update the user database.
Similarly, when something in the user database changes that the core needs to
know about, it would call the core's REST API to make that change.

We would have to design something that would be robust enough to deal with
failures, but I think it could be done.

>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.

Which I think is fine for now.  Without the core, what do you have? :)

>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.

+1

-Barry