[Mailman3-dev] Problem with the schema

[John-Paul Robinson]

On Thu, 31 Mar 2005, J C Lawrence wrote:

> On Thu, 31 Mar 2005 10:40:46 +0100 
> Ian Eiloart <iane at sussex.ac.uk> wrote:
> 
> > Alternatively, viewed from the perspective of a subscriber, rosters
> > are internal nodes and lists are leaf nodes. This isn't really a tree
> > - it's a net.

Yes, it is a net under the hood (when all elements are considered), but
the view from any particular point can be a tree.  So from the perpective 
of the subscriber its a tree stemming from the subscriber address, with 
rosters as internal nodes and lists as leaves.

> It becomes more complex when/if you want to support the concept of a
> user having an account with the system, to which are registered some
> number of email addresses, various connections from both the account and
> individual addresses to rosters and lists, with various arbitrary mail
> policies attached to each address as well as the account to control/hint
> mail flow (eg "For rosters Q, R and S, only send messages shorter than
> NNN to this address").  Yeah, Mailman doesn't want to head there today,
> but that's where MLMs are heading, and fast.

I wouldn't say it becomes even more complex since the individual addresses
are now rooted under a common node (the account).  This is just adding a
parent level to the subscriber view tree.  The point is that while the
objects (lists, rosters, addresses, accounts) are a mesh, the specific
relationships can be trees.  The subscription and list creation actions
relate to defining the relationship links and not reorganizing the objects
into new containers.  If the implementation can handle the
list-roster-address relationships it should be able to add accounts in a
straight forward manner.

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.  Just thinking this through out loud.

~jpr