[Mailman-Developers] Architecture for extra profile info

Stephen J. Turnbull stephen at xemacs.org
Sat Apr 27 07:51:18 CEST 2013


Richard Wackerbarth writes:

 > subscription - the binding of an email address to a list.

Also preferences are bound here.  (This is not the only kind of thing
that preferences can be bound to, but experience shows that we need
per-subscription preferences.)

 > First, rather than having multiple attributes and preferences as
 > "columns" in a table, I would portray them as multiple rows in a
 > table where the attribute names are a key that is used to select
 > the corresponding value.

I have no clue what that sentence means, but I suppose that you mean
that the current representation is something like (in mock-ABNF)

    member := address fullname *attribute

and you want to change that to

    member := address fullname preferences
    preferences := *attribute

 > Additionally, I would generalize the grouping of lists into a
 > hierarchical tree that represents the enterprise organization
 > rather than aspects of the internet namespace.

Example?

 > By treating the preferences as a table of key-value pairs, we can
 > easily extend the list of elements with plug-in modules without
 > having to change the data handling or display mechanisms.

Ah so you don't mean what I wrote above, you want to represent
preferences as a table with

    row = preference-owning-entity att_name att_key

?


More information about the Mailman-Developers mailing list