From claw at kanga.nu Fri Apr 1 05:06:28 2005 From: claw at kanga.nu (J C Lawrence) Date: Fri Apr 1 05:06:33 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: Message from Ian Eiloart of "Thu, 31 Mar 2005 12:21:53 +0100." References: <7B219FC667BB64C033B873CA@lewes.staff.uscs.susx.ac.uk> <18483.1112263536@kanga.nu> Message-ID: <6546.1112324788@kanga.nu> On Thu, 31 Mar 2005 12:21:53 +0100 Ian Eiloart wrote: > --On March 31, 2005 02:05:36 -0800 J C Lawrence wrote: >> On Thu, 31 Mar 2005 10:40:46 +0100 Ian Eiloart >> 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. >> It becomes more complex when/if you want to support the concept of a >> user having an account with the system, > Yes, I do want to do that. In fact I want two types of account: local > and non-local. A local account is one that is already defined on my > LDAP (or whatever) servers - they're students and staff on my > campus. A non-local account type would be closer to what Mailman has > right now - it could use any non-local mail addresses. If we step away from the abstraction a little bit, especially once we've assumed that rosters are first class objects, the situation becomes quite complex: A roster can be populated externally to any list. A list may reference multiple rosters in such a fashion that subscriptions variously accrue to different rosters based on pilicy (eg internal, external). Rosters can be used as the definition of the moderator and owner sets for a list or lists. Lists themselves can be roster members. Rosters can have complex contextual read/write policies. For exmaple: Roster QRS: Can (not) be read by any identity (not) in one of the following rosters... Can only be written to by members of the following rosters... etc etc etc. There's a non-trivial design piece there. > -- Ian Eiloart Servers Team Sussex University ITS Hehn. I used to live not too far down the road from you guys (I was in East Grinstead). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw at kanga.nu Fri Apr 1 05:26:08 2005 From: claw at kanga.nu (J C Lawrence) Date: Fri Apr 1 05:26:11 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: Message from John-Paul Robinson of "Thu, 31 Mar 2005 11:20:35 CST." References: Message-ID: <6793.1112325968@kanga.nu> On Thu, 31 Mar 2005 11:20:35 -0600 (CST) 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)... Why is an address subscribed to a list? Why isn't it the account which then specialised delivery to one of its addresses? > 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. I tend to like looking at these sorts of problem sets as process queues (in the MQS sense). At that point its really is just an FSM with nodes linked by message-passing (not email messages), and certain state transforms able to fork the FSM into multiple new/distinct FSMs. The problem with this view is collapsing the delivery space: a given email, having entered the system, could have spawned a dozen leafnode states by the time it gets ready to exit the system, each of those states ready to dump the email out to an arbitrary set of email addresses extracted from accounts. The (a) problem is then coalescing the leaf states for duplicate address removal. > Seems like it may be best to just have (account,address,list) tuples > for attribute setting and matching. Ehh? Why? Intuitively the following approach seems workable: - Rosters are the primary data type. - Rosters are composed of accounts. - Accounts contain one or more email addresses and policies to control/direct message flow to/for/from those addresses. - Email addresses are special cases of rosters, and have all the properties and capabilities of rosters (same base type). - Lists are accounts with sextra meta-data. - Lists are special(ised) in that they (more easily) accept mail injections from sources outside the system. - Accounts normally only accept mail from other components within the system. - Policy statements glue everything together. - Polices decompose into state trees. - Emails entering the system are dropped into a list (as a specialised account that accepts external mail by policy definition). etc. The final system would probably consist of a few score small cooperative executables, each of which is responsible for one narrow class of state transforms for the set of possible FSMs. (Do one thing, one thing only, and do it well) The FSM set can then be represented/stored on the filesystem (my preference), or in SQL tables as appropriate, subsequent processes initialising from that store and then transforming it to the new state. > Just thinking this through out loud. Also. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry at python.org Fri Apr 1 07:22:31 2005 From: barry at python.org (Barry Warsaw) Date: Fri Apr 1 07:22:35 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: <23704.1112155969@kanga.nu> References: <1112153594.30039.341.camel@presto.wooz.org> <23704.1112155969@kanga.nu> Message-ID: <1112332951.26837.8.camel@geddy.wooz.org> On Tue, 2005-03-29 at 23:12, J C Lawrence wrote: > No. Rosters as first class objects have a set of expiry semantics which > are unique to themselves. Those semantics may be the super-set of the > expiry semantics of the lists which reference them, or some other > arbitrary set (which may cause them to be expired before their dependent > lists expire). To accomplish this, I think Rosters have to be named, or otherwise identified with a human readable label. "Roster 17" or "the Roster containing these 17,000 addresses" won't be a good way to identify a Roster whose linkage to a MailingList has been broken. > I'd treat MessageCollections as another first class object with discrete > semantics. I don't know what LanguageTextCollections are yet. They're things like "the welcome message in the 7 different languages this list supports". Each contains a set of LanguageTexts for a particular message in a specific language. > There are multiple levels of "deletion": > > - Doesn't accept or send mail any more I might call these "dormant". For example, dormant lists can be easily resurrected (I'm thinking Python's SIGs as an example). > - List is invisible to external view but still exists as a set of > meta-data configurations. Such as? Can you provide more detail in what you're thinking here? > > - Doesn't exist as a list configuration but still has archives and > other meta-data Yep. > > - No trace remains. > > - etc. > > As with all these things I'd suggest starting with determining what the > minimum necessary atoms are, what the necessary relationships among > atoms are, and then building from there. I think we have at least a good start on that. I'll try to find some time to describe what we've got. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman3-dev/attachments/20050401/a925df7b/attachment-0001.pgp From barry at python.org Fri Apr 1 07:33:52 2005 From: barry at python.org (Barry Warsaw) Date: Fri Apr 1 07:33:56 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: References: <1112153594.30039.341.camel@presto.wooz.org> Message-ID: <1112333632.26837.21.camel@geddy.wooz.org> On Wed, 2005-03-30 at 10:08, Ian Eiloart wrote: > Sounds to me like you're thinking that a roster is a property of a mailing > list. That must be incorrect, it's the situation that you want to get away > from. Not really, and not the way it's currently designed. But each mailing list is created with its own primary member roster, as well as rosters for its list of owners and moderators. Rosters can be composed though and needn't be that closely tied to a mailing list. > Now, it may be that you want to have some special rosters that exist ONLY > for specific lists. For example, when creating a list FOO in domain BAR, > you might want to create a roster FOO@BAR_recipients for the default > recipient list. you might also want _owners, _moderators, _poster etc. I'd > also want an _exceptions: for people who can't get off a roster like > "staff", but want off of a particular list. All good ideas. Not all are currently embodied in the schema, but some are (you probably want an ultimate blacklist, e.g. people who should never ever be sent an email by the system because they've complained). > While I'm here, it would be nice to have pseudo-users for "posters", with > wildcards like *@example.com to allow all local users to post to a list. I've thought about that. Although it's not there currently, I think with our roster design we could support such things (including rosters which reference external resources that make their recipient lists available through an interface). > This scheme would allow you to delete lists without worrying about losing > rosters, but maintain 2.x functionality for those that don't care about > rosters. You'd delete a list by deleting it's one entry in the LISTS table, > all related entries in the ACLS table, and all the special rosters. You > could disable a list by flagging it as disabled, or (better) setting a > disabled date in the past. Most admins would want to disable a list for a > while before deleting it. Yep, agreed. A big goal for me is keeping MM3 simple for the common use cases -- simpler than it is now! -- without sacrificing flexibility and usability in larger systems. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman3-dev/attachments/20050401/3c296d70/attachment.pgp From barry at python.org Fri Apr 1 07:36:16 2005 From: barry at python.org (Barry Warsaw) Date: Fri Apr 1 07:36:19 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: References: Message-ID: <1112333776.26836.24.camel@geddy.wooz.org> On Wed, 2005-03-30 at 11:58, John-Paul Robinson wrote: > Until a roster is orphaned (no longer has any references) it is not > eligable for deletion (similar to a hard link in a traditional file > system). Note, in cases where the subscribers and rosters come from an > external source, the "zero reference" condition may not be under the > control of mailman. That is, a roster may always have > 0 reference in > this situation and mailman would never try to delete it. True. The external roster may be (to Mailman) just a pointer to an interface, so while that pointer can be deleted, the resources in the external system obviously should never be (through Mailman). -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman3-dev/attachments/20050401/99e7df6e/attachment.pgp From claw at kanga.nu Fri Apr 1 07:36:16 2005 From: claw at kanga.nu (J C Lawrence) Date: Fri Apr 1 07:36:24 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: Message from Barry Warsaw of "Fri, 01 Apr 2005 00:22:31 EST." <1112332951.26837.8.camel@geddy.wooz.org> References: <1112153594.30039.341.camel@presto.wooz.org> <23704.1112155969@kanga.nu> <1112332951.26837.8.camel@geddy.wooz.org> Message-ID: <8151.1112333776@kanga.nu> On Fri, 01 Apr 2005 00:22:31 -0500 Barry Warsaw wrote: > On Tue, 2005-03-29 at 23:12, J C Lawrence wrote: >> No. Rosters as first class objects have a set of expiry semantics >> which are unique to themselves. Those semantics may be the super-set >> of the expiry semantics of the lists which reference them, or some >> other arbitrary set (which may cause them to be expired before their >> dependent lists expire). > To accomplish this, I think Rosters have to be named, or otherwise > identified with a human readable label. "Roster 17" or "the Roster > containing these 17,000 addresses" won't be a good way to identify a > Roster whose linkage to a MailingList has been broken. Absolutely. Of course that can be the human readable version of a machine friendly numeric primary key. >> I don't know what LanguageTextCollections are yet. > They're things like "the welcome message in the 7 different languages > this list supports". Each contains a set of LanguageTexts for a > particular message in a specific language. Ahh, thanks. >> There are multiple levels of "deletion": - Doesn't accept or send >> mail any more > I might call these "dormant". For example, dormant lists can be > easily resurrected (I'm thinking Python's SIGs as an example). Yup. I'd like to note, and not just to be pedantic but because I really don't feel that I've thought through it fully, that it feels like there's a larger set of "partial" states for mailing lists than I listed. >> - List is invisible to external view but still exists as a set of >> meta-data configurations. > Such as? Can you provide more detail in what you're thinking here? The need is to take a list into a state where it appears to have been deleted to everyone involved but me as SysAdm/ListMaster, I then keep the list configuration around as an audit trail, a set of configuration details (eg headers/footers) to copy from when instantiating a new list, etc. This is something I've wanted here and have accomplished under Mailman v2 by turning off password reminders for the list, disabling the email aliases, and flagging the list to not be shown on the listinfo page. > I think we have at least a good start on that. I'll try to find some > time to describe what we've got. Cool. Hope I'm not jumping in too hard here Barry. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry at python.org Fri Apr 1 07:38:05 2005 From: barry at python.org (Barry Warsaw) Date: Fri Apr 1 07:38:09 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: <18483.1112263536@kanga.nu> References: <7B219FC667BB64C033B873CA@lewes.staff.uscs.susx.ac.uk> <18483.1112263536@kanga.nu> Message-ID: <1112333885.26836.27.camel@geddy.wooz.org> On Thu, 2005-03-31 at 05:05, J C Lawrence wrote: > 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"). No kidding it gets more complex! But we thought about this at the sprint and we certainly designed the schema with this model in mind. Whether we've gotten it right or not remains to be seen. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman3-dev/attachments/20050401/ef091e7a/attachment.pgp From iane at sussex.ac.uk Fri Apr 1 10:53:32 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri Apr 1 10:53:34 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: <66E67302-A210-11D9-B3A7-000A959133A8@u.washington.edu> References: <66E67302-A210-11D9-B3A7-000A959133A8@u.washington.edu> Message-ID: <0628A72520B7B1D3875C0EEF@lewes.staff.uscs.susx.ac.uk> > > You're iane and i.eiloart outside of Mailman? I think that would not be > Mailman's problem. Well, perhaps - but it is a simple LDAP lookup to discover that fact - so Mailman could in theory handle it. Currently my MTA rewrites incoming sender addresses with the 'official' address associated with the username - it's in our LDAP database. The problem is that subscribers have to remember what the username is. I wouldn't expect Mailman to know that I also have other accounts - but 'i.eiloart' is just a mail alias for 'iane', so it *could* handle that. >> And, when it comes to addresses... We manage many mail domains here. >> Some are synonymous (susx.ac.uk and sussex.ac.uk, for example), and >> others aren't. Mailman should permit me to define synonymous local >> mail domains so that when iane@susx.ac.uk is allowed to post to a >> list, then iane@sussex.ac.uk is too. > > Yeah, this is one we haven't tackled. > > Anyway, this obviously took quite a bit of changes to Mailman, but it was > certainly worth it for our site, I can't imagine trying to support the > out-of-the-box model here. > > The code is available via http://staff.washington.edu/donn/UWmm.html > We have had some inquiries, though I can't say for sure anyone else > has actually deployed it. It isn't trivial to apply these changes > and make them work at your own site. > > Donn Cave, donn@u.washington.edu > -- Ian Eiloart Servers Team Sussex University ITS From claw at kanga.nu Fri Apr 1 11:03:51 2005 From: claw at kanga.nu (J C Lawrence) Date: Fri Apr 1 11:03:54 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: Message from Ian Eiloart of "Fri, 01 Apr 2005 09:53:32 +0100." <0628A72520B7B1D3875C0EEF@lewes.staff.uscs.susx.ac.uk> References: <66E67302-A210-11D9-B3A7-000A959133A8@u.washington.edu> <0628A72520B7B1D3875C0EEF@lewes.staff.uscs.susx.ac.uk> Message-ID: <13013.1112346231@kanga.nu> On Fri, 01 Apr 2005 09:53:32 +0100 Ian Eiloart wrote: > I wouldn't expect Mailman to know that I also have other accounts - > but 'i.eiloart' is just a mail alias for 'iane', so it *could* handle > that. If you have an account object... And that account object knows all your email addresses, by whatever means, LDAP, policy, regexes, big long table, private phone line to GHod, whatever... And lists via rosters check that account object for a given email address... Then the Account object should be able to return a True/False or whatever other result is needed as applicable. More specifically this doesn't seem a particularly intereting corner. It mostly seems a question of building in the appropriate delegation verbs. >>> And, when it comes to addresses... We manage many mail domains here. >>> Some are synonymous (susx.ac.uk and sussex.ac.uk, for example), and >>> others aren't. Mailman should permit me to define synonymous local >>> mail domains so that when iane@susx.ac.uk is allowed to post to a >>> list, then iane@sussex.ac.uk is too. >> Yeah, this is one we haven't tackled. Does the above seem a reasonable approach? Of course it presumes that the account class supports mix-ins/plug-ins. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From iane at sussex.ac.uk Fri Apr 1 11:10:51 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri Apr 1 11:10:53 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: <1112333776.26836.24.camel@geddy.wooz.org> References: <1112333776.26836.24.camel@geddy.wooz.org> Message-ID: <5C4E954F8327CB1CD2B66ADC@lewes.staff.uscs.susx.ac.uk> --On April 1, 2005 00:36:16 -0500 Barry Warsaw wrote: > On Wed, 2005-03-30 at 11:58, John-Paul Robinson wrote: > >> Until a roster is orphaned (no longer has any references) it is not >> eligable for deletion (similar to a hard link in a traditional file >> system). Note, in cases where the subscribers and rosters come from an >> external source, the "zero reference" condition may not be under the >> control of mailman. That is, a roster may always have > 0 reference in >> this situation and mailman would never try to delete it. > > True. The external roster may be (to Mailman) just a pointer to an > interface, so while that pointer can be deleted, the resources in the > external system obviously should never be (through Mailman). > > -Barry Hmm... just because the resources are still in the external system doesn't mean that it is OK to delete it automatically when it isn't referenced: It could be a fairly complex sql or ldap query, and could contain a sensitive password for the external system. Someone deleting a list won't necessarily be able to recreate the roster. Even if they have permissions in Mailman to do that, they may not have the password, or they may lack the skills to generate the query, or they may lack knowledge of the database structure. In fact, it may be harder to generate a roster that is "just a pointer" than to generate a list. The value of the pointer is not that it is easier to create, but that it is easier to maintain. That goes out of the window if the pointer can be deleted by removing a list. -- Ian Eiloart Servers Team Sussex University ITS From iane at sussex.ac.uk Fri Apr 1 11:14:27 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri Apr 1 11:14:29 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: <13013.1112346231@kanga.nu> References: <66E67302-A210-11D9-B3A7-000A959133A8@u.washington.edu> <0628A72520B7B1D3875C0EEF@lewes.staff.uscs.susx.ac.uk> <13013.1112346231@kanga.nu> Message-ID: <607DB37FFB64BA839FE9F4DE@lewes.staff.uscs.susx.ac.uk> --On April 1, 2005 01:03:51 -0800 J C Lawrence wrote: > On Fri, 01 Apr 2005 09:53:32 +0100 > Ian Eiloart wrote: > >> I wouldn't expect Mailman to know that I also have other accounts - >> but 'i.eiloart' is just a mail alias for 'iane', so it *could* handle >> that. > > If you have an account object... > > And that account object knows all your email addresses, by whatever > means, LDAP, policy, regexes, big long table, private phone line to > GHod, whatever... > > And lists via rosters check that account object for a given email > address... > > Then the Account object should be able to return a True/False or > whatever other result is needed as applicable. > > More specifically this doesn't seem a particularly intereting corner. > It mostly seems a question of building in the appropriate delegation > verbs. > >>>> And, when it comes to addresses... We manage many mail domains here. >>>> Some are synonymous (susx.ac.uk and sussex.ac.uk, for example), and >>>> others aren't. Mailman should permit me to define synonymous local >>>> mail domains so that when iane@susx.ac.uk is allowed to post to a >>>> list, then iane@sussex.ac.uk is too. > >>> Yeah, this is one we haven't tackled. > > Does the above seem a reasonable approach? Of course it presumes that > the account class supports mix-ins/plug-ins. Yes, it looks good to me. -- Ian Eiloart Servers Team Sussex University ITS From sub1.dev.mailman at msquared.id.au Fri Apr 1 10:47:21 2005 From: sub1.dev.mailman at msquared.id.au (Msquared) Date: Fri Apr 1 15:43:29 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: <6793.1112325968@kanga.nu> References: <6793.1112325968@kanga.nu> <18483.1112263536@kanga.nu> Message-ID: <20050401084721.GA2036@sliderule.msquared.com.au> 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... From jpr at uab.edu Fri Apr 1 19:28:09 2005 From: jpr at uab.edu (John-Paul Robinson) Date: Fri Apr 1 19:28:32 2005 Subject: [Mailman3-dev] Problem with the schema In-Reply-To: <6793.1112325968@kanga.nu> Message-ID: If the account is the object that is subscribed to a list, then it seems one could view an account as a form of a roster. That is, an account is a named collection of email addresses where each address could have specific delivery settings (ordinarily it would be just one address that gets the message for a specific list). The account roster would also ordinarily just be a roster with a single administrator, the user/owner. I'm not sure if this improves anything or is reasonable in the implementation, but the relationship comes to mind. On Thu, 31 Mar 2005, J C Lawrence wrote: > On Thu, 31 Mar 2005 11:20:35 -0600 (CST) > 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)... > > Why is an address subscribed to a list? Why isn't it the account which > then specialised delivery to one of its addresses? From jpr at uab.edu Fri Apr 1 19:57:52 2005 From: jpr at uab.edu (John-Paul Robinson) Date: Fri Apr 1 19:57:55 2005 Subject: [Mailman3-dev] design goal(s) of mm3? In-Reply-To: <6793.1112325968@kanga.nu> Message-ID: The comment about thinking of mailman "in the MQS sense" brings a question to mind: what is the design goal of mm3? Is the goal to be (or be on the move towards) a generalized message distribution framework or focus more narrowly on email-as-a-communication-tool application (i.e. a collaboration aid)? It's not that one is better than the other, just curious about the vision and knowning what it would be good to expect to be able to build on top of mailman (or integrate with it) and what would not be reasonable. I'm sorry if I've missed this if it was already covered elsewhere. I scanned through the archives and wiki and didn't see it stand out. Maybe it's stated between the lines. http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FeaturesWeWantToSupport ~jpr On Thu, 31 Mar 2005, J C Lawrence wrote: > On Thu, 31 Mar 2005 11:20:35 -0600 (CST) > John-Paul Robinson wrote: > > > 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. > > I tend to like looking at these sorts of problem sets as process queues > (in the MQS sense). At that point its really is just an FSM with nodes > linked by message-passing (not email messages), and certain state > transforms able to fork the FSM into multiple new/distinct FSMs. The > problem with this view is collapsing the delivery space: a given email, > having entered the system, could have spawned a dozen leafnode states by > the time it gets ready to exit the system, each of those states ready to > dump the email out to an arbitrary set of email addresses extracted from > accounts. The (a) problem is then coalescing the leaf states for > duplicate address removal. > > > Seems like it may be best to just have (account,address,list) tuples > > for attribute setting and matching. > > Ehh? Why? Intuitively the following approach seems workable: > > - Rosters are the primary data type. > > - Rosters are composed of accounts. > > - Accounts contain one or more email addresses and policies to > control/direct message flow to/for/from those addresses. > > - Email addresses are special cases of rosters, and have all the > properties and capabilities of rosters (same base type). > > - Lists are accounts with sextra meta-data. > > - Lists are special(ised) in that they (more easily) accept mail > injections from sources outside the system. > > - Accounts normally only accept mail from other components within the > system. > > - Policy statements glue everything together. > > - Polices decompose into state trees. > > - Emails entering the system are dropped into a list (as a specialised > account that accepts external mail by policy definition). > > etc. The final system would probably consist of a few score small > cooperative executables, each of which is responsible for one narrow > class of state transforms for the set of possible FSMs. (Do one thing, > one thing only, and do it well) The FSM set can then be > represented/stored on the filesystem (my preference), or in SQL tables > as appropriate, subsequent processes initialising from that store and > then transforming it to the new state. > > > Just thinking this through out loud. > > Also. > > -- > J C Lawrence > ---------(*) Satan, oscillate my metallic sonatas. > claw@kanga.nu He lived as a devil, eh? > http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. > From claw at kanga.nu Tue Apr 5 03:02:13 2005 From: claw at kanga.nu (claw@kanga.nu) Date: Tue Apr 5 08:52:35 2005 Subject: [Mailman3-dev] Re: Problem with the schema References: <6793.1112325968@kanga.nu> <18483.1112263536@kanga.nu> <20050401084721.GA2036@sliderule.msquared.com.au> Message-ID: Msquared wrote: > On Thu, Mar 31, 2005 at 11:20:35AM -0600, John-Paul Robinson wrote: > 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. These would seem to be an operation of the form: Change the filter on my account so that mail from lists X/Y/Z are no longer delivered to address FOO and are instead delivered to address BAR. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From iane at sussex.ac.uk Tue Apr 5 18:04:18 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Tue Apr 5 18:04:20 2005 Subject: [Mailman3-dev] Time scale Message-ID: <78F6CF97079CC240A4971CCE@lewes.staff.uscs.susx.ac.uk> Hi, Our senior management is looking to integrate mailing lists into our Managed Learning Environment. Essentially, they want to populate list membership from their Oracle database. They want to put some development effort into this. I want to argue that the development effort would be best focused on Mailman 3, but to do that I'd need to have some idea of timescales. I want to argue that by contributing, we'd be able to ensure that Mailman 3 was easy to integrate with Oracle in ways that were useful to us, (though it looks like that will happen anyway). Does anyone have a feel for when Mailman 3.0 might be available? This year? This summer? Some other time? -- Ian Eiloart Servers Team Sussex University ITS