[Mailman3-dev] Problem with the schema

[Msquared]

On Thu, Mar 31, 2005 at 11:20:35AM -0600, John-Paul Robinson wrote:

> The options you mention seem to be attributes of accounts, addresses,
> rosters, and lists.  Owners, admins, users can set the attributes and
> then as the message "moves" through the delivery net
> (list->roster->address->account) they act as filters to cull
> non-complient messages. Then there are some lists which just apply the
> list-level attribute filters and simply rely on the
> (list->roster->address) path for delivery address expansion.  That is,
> you will get the message as long as it meets the list criteria.  Yuck.
> That could get ugly.  Seems like it may be best to just have
> (account,address,list) tuples for attribute
> setting and matching.

Actually, I quite like the idea of moving the message through the delivery
net, as that would make it much more flexible, powerful, and extensible.
(account,address,list) tuples ignore rosters.  I know that was just an
example you mentioned while thinking out loud, but it does highlight the
fact that adding a column to the tuple to handle roster would be much more
difficult than adding a step in the chain through the delivery net, since
you're changing a data structure that is core to the system.  If the
system were designed to handle arbitrary links in a chain through a
delivery net, adding (or even removing) links would be so much simpler,
since the system is already designed around that flexibility.


On Thu, Mar 31, 2005 at 07:26:08PM -0800, J C Lawrence wrote:

> > The options you mention seem to be attributes of accounts, addresses,
> > rosters, and lists.  Owners, admins, users can set the attributes and
> > then as the message "moves" through the delivery net
> > (list->roster->address->account)...
> 
> Why is an address subscribed to a list?  Why isn't it the account which
> then specialised delivery to one of its addresses?

I am in two minds about this issue.  Technically it's an account that is
subscribed to the list, and the address could be a property of that
subscription.

On the other hand, an address is really a property of an account.

The rationale for linking the list directly to the address is the fact
that the account can be determined from the address, thus reducing
redundancy in the expression of the relationships between the list, the
account, and the email address.

Another good reason for linking directly to the address is that it may be
easier to update an address on multiple lists, and/or easier to move a
group of subscriptions from one address in an account to another.

Also thinking out loud...  :o)


Regards, Msquared...