[Mailman-Developers] Browser ID integration with Mailman

[Richard Wackerbarth]

On Feb 23, 2012, at 5:43 PM, Barry Warsaw wrote:
> The counter argument is that the core's database should only contain the data
> that is needed to do its function.

Yet another argument would be:
The MM suite can be partitioned logically into a message handler, an archiver, an administration-by-mail interface, a web-based interface, and a roster (et. al.) store.

Perhaps the core should store only that data which it, and no other part of the suite utilizes.
Upon receipt of a message, if appropriate, it would forward the message to appropriate subsystems. If it is to be distributed to a roster, it would obtain the current roster from the storage subsystem.

The web UI, administration-by-mail subsystem and the corporate personnel department would interact with the data store in order to make changes to the rosters.

Perhaps this concept is in keeping with the "leaner core schema" approach.
It also has the advantage that the data store is isolated from the MM message handler.
That would make it easier for "large corporation" to implement the store within their existing corporate database.

Richard

>  A leaner core schema means it will be
> easier to migrate and maintain as time goes on.  It also reduces bloat in the
> REST API, even if we provided a generic key/data API (which frankly I don't
> like).
> 
> E.g. if personnel department were central to the core's functionality, by all
> means, let's add it to the schema and expose it in the right places within the
> REST resource model.  If not, then it really shouldn't be part of the core's
> schema.
> 
> Cheers,
> -Barry
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at 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/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9