[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 27, 2013, at 12:51 AM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

> 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.)

Complete agreement.

> 
>> 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

> 
> ?

Correct. But isn't it

row = preference-owning-entity att_name att_value
?