[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