[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 1:19 AM, Florian Fuchs <flo.fuchs at gmail.com> wrote:

> Hi,
> 
> some first thoughts on it:
> 
> 1) It should be self-contained.
> Meaning: It should not depend on any
> mailman/mailman.client/postorius/hyperkitty packages.

Agreed

> 2) Like the core, it should implement a Python-based webserver.
> It doesn't need to run on Ports 80/443, so we don't have to care about
> one of the popular web servers already listening to those ports.
> Also, we definitely don't want admins to have to follow another "how
> to setup mailman.users with Apache/mod_wsgi" howto.
> It should just run if someone says "start" (Maybe it can even hook
> into $ bin/mailman start? I know, that contradicts item 1. ...).

Where it runs is something that should be easily configurable as a part of installation.
To simplify installation, I would advocate that all of the MM subsystem interfaces become self-documentating.
By doing so, much of the configuration could be done through a "discovery" mechanism.

That would provide an easy way to have modular plug-in extensions.
It would also provide a way for Postorius to automatically adapt to the addition of configuration settings or user fields.

> 3) It doesn't need Django.
> Since it will not deliver any HTML (except an oAuth login form -- see
> 5.) and it doesn't need to be integrated into any existing web site,
> we can choose a more light-weight framework.

Here I take exception. Dismissing Django is a restriction that unnecessarily affects the ease of implementation and, in the common case, complicates the integration of the functionality.

Although it could be implemented without Django, it could also be implemented as a Django "app".
An instance of a django server can then serve the functionality.  As an alternative, where appropriate, this "app" would directly "drop in" to an instance of Postorius or an enterprise website.

One of the advantages of Django is that it can be used as a rapid prototyping mechanism. Simplified interfaces to the data are "free" and more elaborate ones can be added in an incremental fashion.
Also, rather than writing custom modules for things such as authentication and REST interfaces, there is the large community of third-party extensions which readily integrate to provide that functionality.

> 4) Adding new content types for user records should be easy, but
> clearly defined.
> We don't know what information applications need to store. Icons,
> essays, avatars, IRC handles, Twiter names, ...
> So we might think about using a schema-less database, but: We don't
> want to make it possible to just manipulate the result JSON and POST
> it back to the resource, possible deleting things other apps need. So
> adding new information types should be a separate process.
> 
> 5) It should implement an oAuth provider.
> This could be used for API authenticaion and to log into
> Postorius/Hyperkitty (even on other servers. Hint: Reputation!)
> We won't need this for a first prototype though. For now we're
> probably fine with 6)
> 
> 6) Like the core it should be accessible with BasicAuth from localhost.
> Ideally, in the future, it should be accessible both via BasicAuth
> from localhost and via oAuth from the outside world...
> 
> Please correct me where I'm being stupid!
> 
> Florian

> 2013/4/18 Terri Oda <terri at zone12.com>:
>> Background for folk new to this discussion:
>> 
>> Currently, all user information is stored in Mailman core, but it's minimal:
>> a real name, a set of email addresses, subscription info, and preferences.
>> Barry suggests that it should stay minimal: only the things Mailman needs to
>> know to correctly deliver mail (which actually doesn't include "real name"
>> but let's leave that as a legacy item for the moment)

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.

>> It's pretty likely that future features of Mailman will want to attach extra
>> information to users.  Some of it will be social-y stuff like user icons for
>> HyperKitty to display in the archives. Other things include metrics like
>> "when did this person last post to the list?" or "how many posts have they
>> made over the lifetime of this list?"  One thing I know of is that Systers
>> requires a short essay for all new subscribers, explaining why they want to
>> join the list.   (And they're considering porting this feature to Postorius,
>> which means we potentially want an answer to "where will the extra profile
>> data get stored?" before their students start coding.)
>> 
>> So...
>> 
>> I think we've sort of agreed that it would be best if whatever we built just
>> had a rest interface and hyperkitty/postorius/whatever would talk to it
>> through there, and could share data that way, but we need a simple prototype
>> that folk (particularly students) will be able to start using, and there's
>> still some internal architecture decisions that need to be made.
>> 
>> Does anyone have time to build such a thing or write up some short
>> architectural documents so a student could build such a thing in relatively
>> short order?  It doesn't have to be the perfect final design, but we
>> probably need a basic starter api for adding, accessing, editing and
>> possibly even removing profile data.
>> 
>> Thoughts?
>> 
>> Terri