[Mailman-Developers] Browser ID integration with Mailman

[Richard Wackerbarth]

On Feb 25, 2012, at 3:37 PM, Barry Warsaw wrote:
> On Feb 21, 2012, at 08:10 AM, Richard Wackerbarth wrote:
>> On Feb 20, 2012, at 7:28 PM, Barry Warsaw wrote:
>>> Yep, it's a big question.  Something could clearly make sense in the core,
>>> e.g. gpg keys for authentication or encryption.  Other, specifically
>>> ui-type data might not make as much sense in the core.  Even if we came up
>>> with a way to extend the core schema and store the data in the core, how
>>> would you access it?  There would probably have to be a generic REST API
>>> for getting key/value data associated with the user in and out of the core.
>> 
>> In general, I think that this will be needed.  Consider what happens when we
>> try to add a "plugin" optional function such as a different archiver.
>> 
>> In general, it will need to have some database stored parameters. Do we then
>> add yet another database?  I think not.  A generic key/value mechanism in the
>> existing database would provide the capability without requiring a custom
>> change to the API.
> 
> Another way to do this, now that we have (what I think is a fairly robust)
> schema migration, you could imagine the plugin would make available a few
> migrations which would add the necessary data to the existing database.  There
> might be problems if you're adding fields to existing model objects, but
> adding purely new tables shouldn't be too much of a problem I'd think.

First,  I would be quite concerned if any plugins alter existing database tables. I see nothing but nightmares
trying to avoid conflicting interactions, naming conventions, etc. From a maintenance point-of-view, adding auxiliary tables rather than additional columns in existing tables is much more manageable.

When it comes to migrations, we need to assure that migration sequences from separate plugins remain commutative.
We will have no control over the order in which a particular installation will adopt particular plugins.

Where possible, I think that it is preferable to avoid add database tables if the scope of reference for those tables extends beyond the plugin itself.
In order to bridge between the UI and the MM core servers, the REST interface would also have to be extended.

On the other hand, implementing the parameter store for a plugin by adding rows to a common parameter database would be able to utilize an existing interface.

Parameters are just key/value pairs that apply to a particular context. Generically, that context is a tuple of [user, list, ...] . If we add "plugin" to that context key, we have can have a generic store that does not need to be changed when a plugin is added.