[Mailman-Developers] New Interface

[Barry Warsaw]

Steve's got it right.  Just a few other thoughts.

On Jun 06, 2016, at 03:35 PM, Stephen J. Turnbull wrote:

>(2) SQLAlchemy (and the underlying RDBMSes) allow you to have optional
>    fields.  This is implemented by storing NULL in the missing field.

I think we'd prefer this method, i.e. that the stylets would be stored in the
existing database, and we'd use NULLs to indicate that a particular style
variable is not set in the stylet.  Thus, when that stylet is applied, it
would just skip over that attribute.

> > 3: If I go for style composabiltiy as described by you then how would
> > I represent that idea in REST and Postorius?  
>
>Basically the same way.

Just sketching things out (IANAWD :)

You'd be able to create new stylets, giving them a name.  For each variable in
a stylet you'd be able to say whether the variable is enabled or not.  If it's
not, then the stylet won't change that variable.  If it is enabled then it can
be set in that stylet.

You probably want to be able to clone and delete stylets too.

You'd then have a second interface which would be for composability.  I think
you should be able to select named stylets and include them in your style
(which would also be named).  You'd be able to reorder the stylets in a style,
add and remove them from the stack, etc.

Bonus would be to keep track of which styles and/or stylets apply to a
particular list so you could do interesting things like:

* find out which lists use(d) a particular style or stylet
* change an existing mailing list by changing a style or stylet (which differs
  from how things work today.

Of course styles and stylets would be exposed in REST, and we'd have to
discuss where those resources live inside the tree.  But we can do that later,
once/if the basic model sketched out here and in Steve's response ends up
making sense.

Cheers,
-Barry