On 27 Jun 2012, at 23:57, Barry Warsaw wrote:
> 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.

I guess it's too late for me to be talking about this because it's all coded. 
But, if there's a choice in the UI, I just think that in the real world, we'd 
talk about "members" of an organisation being people, or other organisations. 
It might be that the only information you have about a member is their email 
address, so that works too.

Then we'd talk about "membership" or "subscription" records, which would tell 
you who the member was, and various things about their membership (like when it 
started, communication preferences, and so on). So, I just think "membership" 
would be a more natural description of that record, and therefore slightly 
easier for newcomers to understand.

>> 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 a...@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-model
> 
> Contributions welcome of course!
> 
> Cheers,
> -Barry



-- 
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148

_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Reply via email to