On Jun 27, 2012, at 10:23 AM, Ian Eiloart wrote:
There is an IPreferences interface which describes the kind of things that are "preferences". Members, users, and addresses all can have a pointer to a preferences record. There are also some system default preference values. When we look up a preference on a member, the search order goes like this:
- member
- address
- user
- system
Do you mean "membership"? If I (a user) am a member of a list, then I have a membership record.
It means that you-the-user or you-an-address-you-control is linked to the mailing list through the member record.
But, the member is the user.
Not really. It's perfectly valid for a member record to link a mailing list to an address which is not associated with any user record. Members link addresses to mailing lists. The shortcut of linking a user to a mailing list is only valid if that user has a preferred address.
If the term "member record" is used to describe a membership record, things are going to get confusing, I think. Or, perhaps it's a subscription (but still not a subscriber) record?
Member records represent subscriptions to mailing lists as a recipient of messages sent to the list. But they also represent other mailing list roles, such as list-owners and list-moderators. So let's say anne@example.com is a member of a mailing list, and the list owner. Her address record will be linked to two member records, one with role "member" and the other with role "owner".
This might seem confusing at first, but I've lived with this terminology for a long time, after many clarifying steps, and I think this works the best. Once you understand the relationship of users, addresses, members, and mailing lists, it shouldn't be confusing.
To be more explicit, I'd expect a "members" table to simply list references to users.
It can't because of the types of relationships we want to support, such as:
- A user subscribing multiple addresses to a mailing list.
- A user serving more than one role for a mailing list.
- Subscribing non-user addresses to mailing list, e.g. mailbots
- Subscribing a user's preferred address, which can easily be changed system-wide.
Memberships link addresses to mailing lists. They *can* link a user to a mailing list, but only if that user has a preferred address.
Whereas a "subscriptions" or "memberships" table would include references to members, as well as information about the subscription (preferred mailing address, start date, permission type, subject line munging, etc, etc).
I'm not sure what a "member" would be if not essentially equivalent to a subscription. IOW, when you say "expect a members table to simply list references to users", I don't see how that's useful as an independent concept.
My guess is that the link to users is implied, though?
In the case where a member links an address to a mailing list, and that address is linked to a user, then you're correct. :).
Through queries (hidden behind other interfaces, such as the IRoster) we can always find the list of users that are subscribed to a mailing list, although of course user-less addresses won't show up there.
Stephen did a pretty good job of explaining all this very succinctly. A diagram would help, but I suck at ascii art. ;)
http://packages.python.org/mailman/src/mailman/docs/8-miles-high.html#user-m...
Contributions welcome of course!
Cheers, -Barry