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.

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

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.

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@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)

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

---

Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/f%40state-of-mind....

Security Policy: http://wiki.list.org/x/QIA9