[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 11:26 AM, Terri Oda <terri at zone12.com> wrote:

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

Clearly, if you are going to follow (2) below, you will need to interface to MM-core for the portion that is stored there.

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

Notice that I indicate that this is an option.  Although, in the long run, I think it is the right way to go, getting there can be a migration and not something that needs to happen all at once.
> 
> 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.

I thought that we were viewing this as a service accessed through a REST interface. MM core need never know if it is implemented using Django or FORTRAN or ...

Why is depending on some part of Django prohibited when core uses zope, storm, ... ?
Dependencies are just dependencies. As long as they are stable and readily available, why not use those that are useful?

>  Plus, we're going to have to care a lot more about speed and all.

Much of the user information is not needed in the message handler (where speed is a consideration).

Functions such as administration-by-mail that need to access the information are much less critical.
Further, I will argue that those functions should be factored out of the "core" and exist as separate components.

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

I would agree except to the extent that Postorius references the user information.
I believe that all user data should be accessed from the same source. I consider it poor design for the consumer of data to have to keep track of where particular parts of the data are stored.

> 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