From mark at pdc-racing.net Thu Apr 1 15:31:46 2004 From: mark at pdc-racing.net (Mark Dadgar) Date: Thu Apr 1 15:33:29 2004 Subject: [Mailman3-dev] HTML Digests Message-ID: <988541BE-841B-11D8-9E49-000A95DA10EE@pdc-racing.net> One of my subscribers asked if HTML digests were available under Mailman. He pointed out that the ability to click on a subject in the TOC and automatically skip down to the appropriate post would be a really cool feature. Even though I am hardly a proponent of HTML email, I cannot help but see the benefit in this if were an option at the administrator's discretion. - Mark ----- mark@pdc-racing.net From barry at python.org Thu Apr 1 17:58:52 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 1 17:58:58 2004 Subject: [Mailman3-dev] HTML Digests In-Reply-To: <988541BE-841B-11D8-9E49-000A95DA10EE@pdc-racing.net> References: <988541BE-841B-11D8-9E49-000A95DA10EE@pdc-racing.net> Message-ID: <1080860332.5481.23.camel@anthem.wooz.org> On Thu, 2004-04-01 at 15:31, Mark Dadgar wrote: > One of my subscribers asked if HTML digests were available under > Mailman. He pointed out that the ability to click on a subject in the > TOC and automatically skip down to the appropriate post would be a > really cool feature. > > Even though I am hardly a proponent of HTML email, I cannot help but > see the benefit in this if were an option at the administrator's > discretion. I agree, and given that we're planning on having a message store, it makes things like this possible for Mailman 3. -Barry From mark at pdc-racing.net Thu Apr 1 19:27:25 2004 From: mark at pdc-racing.net (Mark Dadgar) Date: Thu Apr 1 19:27:31 2004 Subject: [Mailman3-dev] HTML Digests In-Reply-To: <1080860332.5481.23.camel@anthem.wooz.org> References: <988541BE-841B-11D8-9E49-000A95DA10EE@pdc-racing.net> <1080860332.5481.23.camel@anthem.wooz.org> Message-ID: <84418122-843C-11D8-9E49-000A95DA10EE@pdc-racing.net> On Apr 1, 2004, at 2:58 PM, Barry Warsaw wrote: >> One of my subscribers asked if HTML digests were available under >> Mailman. He pointed out that the ability to click on a subject in the >> TOC and automatically skip down to the appropriate post would be a >> really cool feature. >> >> Even though I am hardly a proponent of HTML email, I cannot help but >> see the benefit in this if were an option at the administrator's >> discretion. > > I agree, and given that we're planning on having a message store, it > makes things like this possible for Mailman 3. I think my subscriber was actually thinking of the case where you click on a subject in the digest TOC and it skips down to the appropriate post IN THE EMAIL MESSAGE, as opposed to linking to the message store on the web (which could be problematic if you have private archives). Although that is certainly a cool feature, too. Particularly for subscribers with limited email storage space. - Mark From claw at kanga.nu Fri Apr 2 01:02:49 2004 From: claw at kanga.nu (J C Lawrence) Date: Fri Apr 2 01:02:54 2004 Subject: [Mailman3-dev] Threaded moderation interface Message-ID: <6623.1080885769@kanga.nu> This is actually something I need/want for Mailman v2.1, but v3 seems more likely: I'd like a view of the moderation interface that displays held messages in terms of threads, and allows action on both individual messages and entire threads. Among other things this would allow easier "best-of" list operation. -- 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 2 03:57:15 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Fri Apr 2 03:57:19 2004 Subject: [Mailman3-dev] HTML Digests In-Reply-To: <988541BE-841B-11D8-9E49-000A95DA10EE@pdc-racing.net> References: <988541BE-841B-11D8-9E49-000A95DA10EE@pdc-racing.net> Message-ID: <2147483647.1080899835@beeding.central.susx.ac.uk> --On Thursday, April 1, 2004 12:31 pm -0800 Mark Dadgar wrote: > One of my subscribers asked if HTML digests were available under Mailman. > He pointed out that the ability to click on a subject in the TOC and > automatically skip down to the appropriate post would be a really cool > feature. Well, that works for people that happen to have mail clients which support that feature. I guess it couldn't hurt much to add it as an option. However, I'd like to see better support of MIME digests. I use mulberry, which shows me a list of mime attachements. I can see how many messages I have in the digest, their content type, size and name. Unfortunately, the parts are all named like this: "Unnamed Part #1" "Unnamed Part #2" "Unnamed Part #3_1_1" "Unnamed Part #3_2_1" "Unnamed Part #4" Consistently, #1 is the message "header" boiler plate text - btw, can't we call that something different to distinguish it from email headers. "Leader" text, for example. #?2 is the TOC # 3_n_1 is the nth message # 4 is the message footer. Mulberry displays the message in two panes, with the part list in the top pane, and the selected MIME part in the bottom pane. I can skip back to Part #2 to select the next interesting part to view, ***feature request*** but it would be so much easier if the MIME parts were named for the subject text and sender name, for example. ***/feature request*** Actually, I prefer to get undigested messages, filter them using the RFC 2369 headers, and view the mailbox properly threaded. -- Ian Eiloart Servers Team Sussex University ITS From dev at elevatorup.com Sat Apr 3 16:57:26 2004 From: dev at elevatorup.com (Aaron Schaap) Date: Sat Apr 3 22:47:18 2004 Subject: [Mailman3-dev] Mailman Design Message-ID: I'm not quite sure how to start this up but I'd like to discuss the idea of enhancing the design of Mailman. Is there a group of people currently working on this? If not, I'd like to start one and do a little brainstorming on how to make Mailman a little better. Right now I'm just playing around with changing Mailman to be XHTML and CSS compliant within the "Edit HTML options" placed within the administrator's section. This is more for me to get familiar with the program. For those that have been working on this much longer than I, I'd like to hear what you are thinking. ------------------------- Aaron Schaap Elevator Up - Internet Consulting & Development Phone: 616-566-1423 Web: www.elevatorup.com Email: aaron.schaap@elevatorup.com From mk2s at digitalcommute.com Sun Apr 4 11:44:46 2004 From: mk2s at digitalcommute.com (Michael Kato) Date: Sun Apr 4 12:16:07 2004 Subject: [Mailman3-dev] PyProtocols vs. Zope Interfaces Message-ID: <00155A77-864F-11D8-9559-000A95AB83D2@digitalcommute.com> Barry, I too like the Zope3's new way of specifying "implements". Does zope3's interface still have the packaging issue of being too big and zope dependant? If so, we could talk to the PEAK/pyprotocols people and see if they can implement the new zope way, or even implement this ourselves.(into pyprotocols and give it back) I've-always-wanted-to-muck-with-metaclasses-ly yours, ....maki.... >> I think I'm beginning to understand the Interface thing. It seem >> that in the PEAK PyProtocols the way to say a class implements an >> interface is: >> >> class XXX(object): >> >> def .... >> >> advise(instancesProvide = [IUser]) > > Doesn't that seem a bit too verbose? Zope3's New Way would be: > > class XXX(object): > implements(IUser) > > I like that! > >> I was looking for a way to find out if an object implements a >> protocol, but I think that turns out to be just applying adapt(). One >> of the points of the Interfaces being eliminating isinstance() like >> querying. Just adapt() and use. > > Yep. In Zope3's interfaces now we'd do something like: > > user = IUser(obj) > > but of course, we'd have to deal somehow with the resulting TypeError. > (Or use IUser(obj, None) and deal with the None return value). > >> I know you originally mentioned that the Interfaces were mostly for >> documentation, but do we want to do the adapt() thing? For instance >> the contract of get_user() from an IUserStorage says it will return an >> object that implements IUser. Once we get that result back do we want >> to always say user=adapt(result, IUser) before we use the result? I >> see one advantage to that being that the backend has some wiggle room >> in returning non object instances like a module or a class and it'll >> have a chance for the adapt() voodoo to be worked or people to write >> real adapters etc. On the other hand I fear that might be too much >> engineering. > > Me too. I'd opt for simplicity for now. If we find we need to start > adapting objects we can add the machinery to do that. One place I've > been thinking about using adaptation is for places where we're going to > be exposing attributes through things like page templates or variable > substitutions in mail messages. In that case, I think we want to > figure > out some way to adapt an object so that /only/ the values we want to > expose are accessible. From barry at python.org Sun Apr 4 13:27:18 2004 From: barry at python.org (Barry Warsaw) Date: Sun Apr 4 13:27:38 2004 Subject: [Mailman3-dev] PyProtocols vs. Zope Interfaces In-Reply-To: <00155A77-864F-11D8-9559-000A95AB83D2@digitalcommute.com> References: <00155A77-864F-11D8-9559-000A95AB83D2@digitalcommute.com> Message-ID: <1081099637.25863.59.camel@anthem.wooz.org> On Sun, 2004-04-04 at 11:44, Michael Kato wrote: > I too like the Zope3's new way of specifying "implements". Does > zope3's interface still have the packaging issue of being too big and > zope dependant? I'm not sure. I need to re-capture current Zope3's interface package and see what the dependencies are. I've been discouraged by Zope3 page template dependencies. The last time I capture them I found that we had to pull in the following subpackages: zope.tal zope.tales zope.pagetemplates (okay, those make sense :) zope.interface zope.i18n (those make sense too) zope.i18nmessageid (I suppose, but that was a new one) zope.schema (huh?) I mentioned this to a few other ZC folks last week and certainly the zope.schema dependency was a surprise. Maybe that's just a bug. > If so, we could talk to the PEAK/pyprotocols people > and see if they can implement the new zope way, or even implement this > ourselves.(into pyprotocols and give it back) +1 > I've-always-wanted-to-muck-with-metaclasses-ly yours, Ultimately I'd love to see a PEP 246 implementation in Python proper, but I'm sure that's at least several major releases away, if ever. So, I'll send Phillip a message about the new Zope idioms and see if he thinks that would make sense for PyProtocols. -Barry From mlm at kaibren.com Sun Apr 4 17:13:58 2004 From: mlm at kaibren.com (MLM Subscriber) Date: Sun Apr 4 17:14:19 2004 Subject: [Mailman3-dev] Include real name in Roster view Message-ID: <6.0.3.0.2.20040404171006.03020ec0@localhost> In mailman 2, I created a patch so the roster view (from the listinfo page) shows real names as well as (obfuscated or actual) email addresses. This should be a supported option in MM3. Ideally there would be a config attribute similar to the "Obscure addresses" attribute for listing fullnames in the roster views. (I am tired of having to reapply the patch for each release. Can I get it added to the mm2 tree?) ---sample roster view--- 57 Non-digested Members of MyList: "Alice Wonder" < smile at comcast.net > "Ann & Dave" < drifters at jolimail.com > "Bonnie Smith" < holdup at aol.com > "Mary & Josh Hess" < disciples at verizon.net > Etc. ---- /usr/local/mailman/Mailman/# diff HTMLFormatter.py.dist HTMLFormatter.py 92c92 < showing = Utils.ObscureEmail(person, for_text=1) --- > email = Utils.ObscureEmail(person, for_text=1) 94c94,100 < showing = person --- > email = person > > fullname = Utils.uncanonstr(self.getMemberName(person), lang) > if fullname: > showing = '"%s" < %s >' % (fullname, email) > else: > showing = email Patched file reads: ... for person in people: id = Utils.ObscureEmail(person) url = self.GetOptionsURL(person) if self.obscure_addresses: email = Utils.ObscureEmail(person, for_text=1) else: email = person fullname = Utils.uncanonstr(self.getMemberName(person), lang) if fullname: showing = '"%s" < %s >' % (fullname, email) else: showing = email ... From barry at python.org Mon Apr 5 10:17:21 2004 From: barry at python.org (Barry Warsaw) Date: Mon Apr 5 10:17:47 2004 Subject: [Mailman3-dev] Include real name in Roster view In-Reply-To: <6.0.3.0.2.20040404171006.03020ec0@localhost> References: <6.0.3.0.2.20040404171006.03020ec0@localhost> Message-ID: <1081174640.29721.21.camel@anthem.wooz.org> On Sun, 2004-04-04 at 17:13, MLM Subscriber wrote: > In mailman 2, I created a patch so the roster view (from the listinfo page) > shows real names as well as (obfuscated or actual) email addresses. I think that's a good idea, but we need to rethink the u/i for roster views (and membership access in general). The current approach doesn't scale when you have something like 200k addresses in your list. > This should be a supported option in MM3. Ideally there would be a config > attribute similar to the "Obscure addresses" attribute for listing > fullnames in the roster views. (I am tired of having to reapply the patch > for each release. Can I get it added to the mm2 tree?) Did you post your patch to SourceForge? -Barry From barry at python.org Mon Apr 5 10:22:57 2004 From: barry at python.org (Barry Warsaw) Date: Mon Apr 5 10:23:24 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: References: Message-ID: <1081174976.29721.28.camel@anthem.wooz.org> On Sat, 2004-04-03 at 16:57, Aaron Schaap wrote: > I'm not quite sure how to start this up but I'd like to discuss the idea of > enhancing the design of Mailman. By "design" do you mean the web u/i for Mailman? If so, +1 and yep, this is the place to be. > Is there a group of people currently working on this? If not, I'd like to > start one and do a little brainstorming on how to make Mailman a little > better. > > Right now I'm just playing around with changing Mailman to be XHTML and CSS > compliant within the "Edit HTML options" placed within the administrator's > section. This is more for me to get familiar with the program. We need to rethink how (or even if) the u/i will be editable through the web. There are all kinds of security and xss issues that need to be addressed if we allow this. I tend to think it fails the 80/20 rule -- it makes the system more complex for a feature that few use. OTOH, I'm a strong +1 on having a better u/i for MM3, and I think modern developments like XHTML, CSS, and (modest and optional) JavaScript are on the table. We definitely want to do as much of the web u/i in a templating language as possible. I'm currently favoring Zope3's page template implementation because it supports i18n. It would be great if you'd like to help work on this aspect of MM3. -Barry From dev at elevatorup.com Mon Apr 5 13:52:16 2004 From: dev at elevatorup.com (Aaron Schaap) Date: Mon Apr 5 13:52:58 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: <1081174976.29721.28.camel@anthem.wooz.org> Message-ID: > By "design" do you mean the web u/i for Mailman? If so, +1 and yep, > this is the place to be. Yes, I mean u/i. > We need to rethink how (or even if) the u/i will be editable through the > web. There are all kinds of security and xss issues that need to be > addressed if we allow this. I tend to think it fails the 80/20 rule -- > it makes the system more complex for a feature that few use. I agree it's not the best to have everything editable. However, that said, if we do quite a bit of it in CSS, with everything nicely structured and semantic - people should be able to do quite a bit with the CSS file as far as look and layout. Example: CSS Zen Garden http://csszengarden.com/ This was a project in which designers had to come up with various designs for the same site. The only catch was that they couldn't touch the HTML and could only change the CSS to make their designs come alive. Using this method, I think we can offer people a huge amount of flexibility by allowing them to change one single CSS file. This is however, just one idea and much more conversation is needed. ------------------------- Aaron Schaap Elevator Up - Internet Consulting & Development Phone: 616-566-1423 Web: www.elevatorup.com Email: aaron.schaap@elevatorup.com From mk2s at digitalcommute.com Tue Apr 6 00:45:45 2004 From: mk2s at digitalcommute.com (Michael Kato) Date: Tue Apr 6 00:45:50 2004 Subject: [Mailman3-dev] test cases now work for bdb Message-ID: <444814B7-8785-11D8-B30E-000A95AB83D2@digitalcommute.com> Barry, I've rearranged the testcases(the three that I have so far) so that they can be run against the bdb backend as well as the stubbackend. I've come accross some questions. Given a email address either from a post or from a web login, how do we get the User object for this user? Do I create an Address and ask it for the user? I was thinking get_user(uid, domain) should perhaps throw an exception(InvalidDomainError?) when passed a bogus domain. So, I wrote a test case for that, and added code to the stubimpl and the tests went green. Then I tried it with the bdbbackend and it didn't(as it only throws a NoUserError). So I changed my implementation to match yours. Do we assume, that domains are checked before we get to that point? If so, do we already have a way to check a domain? I know the info is available in the config, shall I write that routine? Where should it go? Anyway, if you're interested, you could run the test (after configuring backendtest.conf) like: python ./testUserOps.py ....maki.... PS. I had to add a vardir and a lockdir into webserver.conf to get the webserver to start. From barry at python.org Tue Apr 6 13:16:09 2004 From: barry at python.org (Barry Warsaw) Date: Tue Apr 6 13:16:15 2004 Subject: [Mailman3-dev] test cases now work for bdb In-Reply-To: <444814B7-8785-11D8-B30E-000A95AB83D2@digitalcommute.com> References: <444814B7-8785-11D8-B30E-000A95AB83D2@digitalcommute.com> Message-ID: <1081271769.30379.116.camel@anthem.wooz.org> On Tue, 2004-04-06 at 00:45, Michael Kato wrote: > I've rearranged the testcases(the three that I have so far) so that > they can be run against the bdb backend as well as the stubbackend. Very cool, thanks! One of the things on my list is to get test.py working again. This should be the standard way of running the entire test suite. Right now it's broken because some of the tests are woefully out of date. > I've come accross some questions. > > Given a email address either from a post or from a web login, how do > we get the User object for this user? Do I create an Address and ask > it for the user? I've been thinking about this just last night, especially w.r.t. subscriptions. I'm currently thinking we use the storage to create an IUser, and then call add_address() on that to get an IAddress. The label can be something like 'default'. Then we set the .address attribute on the IAddress, and possibly .realname too. What we don't currently have though is a query interface. I.e. given an address, can we find the user that address is associated with. We need to add something like a find_user(address, domain) to the IUserStorage interface. > I was thinking get_user(uid, domain) should perhaps throw an > exception(InvalidDomainError?) when passed a bogus domain. So, I wrote > a test case for that, and added code to the stubimpl and the tests went > green. Then I tried it with the bdbbackend and it didn't(as it only > throws a NoUserError). So I changed my implementation to match yours. > > Do we assume, that domains are checked before we get to that point? > If so, do we already have a way to check a domain? I know the info is > available in the config, shall I write that routine? Where should it > go? My current thinking is that the domain argument to the IUserStorage methods will come from the config mapping. I.e. if we get an email, we'll know which mailhost it comes from (likewise for webhost for a web hit). Thus if I have something like domain python python.org www.python.org then at the interface level, I can always expect to see the domain value be 'python'. That's probably what we'll use for the listid too, e.g. 'mailman3-dev@python'. So yep, the checking should happen earlier. The test can always do something like: failUnless(domain in configuration.mailman.bydomain) (and yep, it would be good to have such a test :) > Anyway, if you're interested, you could run the test (after > configuring backendtest.conf) like: > python ./testUserOps.py Cool, I'll try that later tonight. > ....maki.... > PS. I had to add a vardir and a lockdir into webserver.conf to get the > webserver to start. Ah, I'd forgotten to add that -- thanks! -Barry From mtech at duane.com Wed Apr 7 21:04:07 2004 From: mtech at duane.com (mtech@duane.com) Date: Wed Apr 7 21:14:20 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: from "Aaron Schaap" at Apr 05, 2004 01:52:16 PM Message-ID: <20040408010407.D842DE242A8@ns1.duane.com> Aaron Schaap wrote > > >> By "design" do you mean the web u/i for Mailman? If so, +1 and yep, >> this is the place to be. > >Yes, I mean u/i. I still feel that it would be a good thing to provide a simple, html based user interface that had these items on the left side of the listinfo page to navigate through the different options rather than the blast of text that now happens. [subscribe] {archives} {list options} {members} {post} Is this something that could be added in Mailman 2.1.5 or 2.2 ? >> We need to rethink how (or even if) the u/i will be editable through the >> web. There are all kinds of security and xss issues that need to be >> addressed if we allow this. I tend to think it fails the 80/20 rule -- >> it makes the system more complex for a feature that few use. > >I agree it's not the best to have everything editable. However, that said, >if we do quite a bit of it in CSS, with everything nicely structured and >semantic - people should be able to do quite a bit with the CSS file as far >as look and layout. > >Example: CSS Zen Garden >http://csszengarden.com/ > >This was a project in which designers had to come up with various designs >for the same site. The only catch was that they couldn't touch the HTML and >could only change the CSS to make their designs come alive. > >Using this method, I think we can offer people a huge amount of flexibility >by allowing them to change one single CSS file. > >This is however, just one idea and much more conversation is needed. > >------------------------- >Aaron Schaap >Elevator Up - Internet Consulting & Development >Phone: 616-566-1423 >Web: www.elevatorup.com >Email: aaron.schaap@elevatorup.com > > > >_______________________________________________ >Mailman3-Dev mailing list >Mailman3-Dev@python.org >Unsubscribe: http://mail.python.org/mailman/options/mailman3-dev/mtech%40duane.com > From barry at python.org Wed Apr 7 21:02:07 2004 From: barry at python.org (Barry Warsaw) Date: Wed Apr 7 22:02:03 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: <20040408010407.D842DE242A8@ns1.duane.com> References: <20040408010407.D842DE242A8@ns1.duane.com> Message-ID: <1081386122.1489.118.camel@geddy.wooz.org> On Wed, 2004-04-07 at 21:04, mtech@duane.com wrote: > I still feel that it would be a good thing to provide a simple, > html based user interface that had these items on the left > side of the listinfo page to navigate through the different options > rather than the blast of text that now happens. > > [subscribe] > {archives} > {list options} > {members} > {post} > > Is this something that could be added in Mailman 2.1.5 or 2.2 ? Practically speaking, it's not likely. There are only so many round tuits available so I don't currently think there is going to be a 2.2. There will be a 2.1.5, but a micro release isn't the right place to be radically redesigning the default u/i. Mailman 3 is going to be the best place for u/i spifification. :) -Barry From barry at python.org Thu Apr 8 08:52:55 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 8 08:53:01 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: <20040408075120.GB2053@rezo.net> References: <20040408010407.D842DE242A8@ns1.duane.com> <1081386122.1489.118.camel@geddy.wooz.org> <20040408075120.GB2053@rezo.net> Message-ID: <1081428774.4109.57.camel@anthem.wooz.org> On Thu, 2004-04-08 at 03:51, Fil wrote: > Anyway, if we just listed all that exists we'd have prototypes for new > interfaces. Good idea: http://zope.org/Members/bwarsaw/MailmanDesignNotes/WebUIMockupsAndNotes -Barry From fil at rezo.net Thu Apr 8 03:51:20 2004 From: fil at rezo.net (Fil) Date: Thu Apr 8 08:53:32 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: <1081386122.1489.118.camel@geddy.wooz.org> References: <20040408010407.D842DE242A8@ns1.duane.com> <1081386122.1489.118.camel@geddy.wooz.org> Message-ID: <20040408075120.GB2053@rezo.net> > > [subscribe] > > {archives} > > {list options} > > {members} > > {post} I'm sure many of us already have designed elements of such things; for my part I've done a popup subscription form that you can see for example at http://mondediplo.com/ ; it is multilingual and GPLed (though not yet downloadable). It's written in php. It does use the command line tools and email to interact with Mailman, so it's quite hacky :-) Anyway, if we just listed all that exists we'd have prototypes for new interfaces. -- Fil From barry at python.org Thu Apr 8 20:38:39 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 8 20:38:47 2004 Subject: [Mailman3-dev] HTML Digests In-Reply-To: <2147483647.1080899835@beeding.central.susx.ac.uk> References: <988541BE-841B-11D8-9E49-000A95DA10EE@pdc-racing.net> <2147483647.1080899835@beeding.central.susx.ac.uk> Message-ID: <1081471118.5071.10.camel@anthem.wooz.org> On Fri, 2004-04-02 at 03:57, Ian A B Eiloart wrote: > Mulberry displays the message in two panes, with the part list in the top > pane, and the selected MIME part in the bottom pane. I can skip back to > Part #2 to select the next interesting part to view, ***feature request*** > but it would be so much easier if the MIME parts were named for the subject > text and sender name, for example. ***/feature request*** That still better than what Evolution does, since as of 1.4.x it still doesn't understand digest attachments. VM under XEmacs was the best. You could actually burst a digest (either RFC 1153 "plain text" digests or MIME digests) into a folder so that it would look like all those messages came separately. Too bad VM doesn't have real IMAP support. :/ -Barry From barry at python.org Thu Apr 8 20:39:44 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 8 20:39:50 2004 Subject: [Mailman3-dev] HTML Digests In-Reply-To: <84418122-843C-11D8-9E49-000A95DA10EE@pdc-racing.net> References: <988541BE-841B-11D8-9E49-000A95DA10EE@pdc-racing.net> <1080860332.5481.23.camel@anthem.wooz.org> <84418122-843C-11D8-9E49-000A95DA10EE@pdc-racing.net> Message-ID: <1081471184.5071.12.camel@anthem.wooz.org> On Thu, 2004-04-01 at 19:27, Mark Dadgar wrote: > I think my subscriber was actually thinking of the case where you click > on a subject in the digest TOC and it skips down to the appropriate > post IN THE EMAIL MESSAGE, as opposed to linking to the message store > on the web (which could be problematic if you have private archives). I'm not sure how you'd do that. Maybe using a multipart/related where the subparts where linked via internal links (I forget the RFC at the moment). -Barry From barry at python.org Thu Apr 8 20:41:25 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 8 20:41:33 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: References: Message-ID: <1081471284.5071.15.camel@anthem.wooz.org> On Mon, 2004-04-05 at 13:52, Aaron Schaap wrote: > I agree it's not the best to have everything editable. However, that said, > if we do quite a bit of it in CSS, with everything nicely structured and > semantic - people should be able to do quite a bit with the CSS file as far > as look and layout. That's not a bad idea. Editing CSS should be harmless, right? I mean is there the equivalent of cross-site scripting exploits possible if all you give is the ability to edit CSS? > Example: CSS Zen Garden > http://csszengarden.com/ Yep, I've seen that site. Very impressive! :) -Barry From barry at python.org Thu Apr 8 20:43:36 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 8 20:43:50 2004 Subject: [Mailman3-dev] Add ability for admin to change email addresses inside List database In-Reply-To: <1079626999.4514.9.camel@localhost.localdomain> References: <5.1.0.14.2.20040318100914.02cd4e30@pop.mindspring.com> <1079626999.4514.9.camel@localhost.localdomain> Message-ID: <1081471416.5071.18.camel@anthem.wooz.org> On Thu, 2004-03-18 at 11:23, Jon Carnes wrote: > > The problem I've been having is that there doesn't seem to be a way > for the LIST ADMIN to change a subscriber's e-mail address without a > confirmation (unless one goes through a subscribe/unsubscribe which > risks changing user options and the user password). For these > particular communities we really do not want confirmation required -- > and if it's not required for the initial subscription, why is it > required for the address change? > > > > That's a nice feature and a good justification for it. I'll forward > that along to the MMv3 list and see if folks like it. I've had the same frustration, and I agree that a list admin should have a convenient way to change a user's email address without a confirmation dance. -Barry From barry at python.org Thu Apr 8 20:46:00 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 8 20:46:12 2004 Subject: [Mailman3-dev] Threaded moderation interface In-Reply-To: <6623.1080885769@kanga.nu> References: <6623.1080885769@kanga.nu> Message-ID: <1081471560.5071.22.camel@anthem.wooz.org> On Fri, 2004-04-02 at 01:02, J C Lawrence wrote: > This is actually something I need/want for Mailman v2.1, but v3 seems > more likely: > > I'd like a view of the moderation interface that displays held > messages in terms of threads, and allows action on both individual > messages and entire threads. Most of the lists I admin probably wouldn't benefit much from a threaded moderation interface, but I can see where it would be useful for some lists. OTOH, what I /really/ want is access to the admindb through a real mail client, i.e. IMAP. I'm personally just not a big fan of rendering email in HTML for a lot of reasons, so it should /at least/ be possible to interact with a mailing list with real mail readers. > Among other things this would allow easier "best-of" list operation. I'm not sure I follow. Could you explain what you mean? -Barry From barry at python.org Thu Apr 8 20:53:57 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 8 20:54:05 2004 Subject: [Mailman3-dev] anti-spam related features In-Reply-To: <2147483647.1079449326@beeding.central.susx.ac.uk> References: <200403151905.i2FJ5O7H025634@agora.fsl.cs.sunysb.edu> <1079389698.5149.319.camel@anthem.wooz.org> <2147483647.1079449326@beeding.central.susx.ac.uk> Message-ID: <1081472037.5071.30.camel@anthem.wooz.org> On Tue, 2004-03-16 at 10:02, Ian A B Eiloart wrote: > --On lunes, 15 marzo 2004 17:28 -0500 Barry Warsaw wrote: > > > > > I'd also like to see some integration efforts with Spambayes. Getting a > > generic interface and U/I for this stuff is going to be tricky. > > I don't know if this is generally the case, but our spam filter > (bogofilter) adds a header, which can be easily parsed. A generic interface > would just match a specified header with a regular expression to extract > some number - that's a site configuration, so U/I isn't that important. I'm definitely thinking that we'll want spam controls to follow a similar pattern we developed in the sprint for the flow of options and user control (yes, Maki, I know I still need to scan those diagrams in! :) The idea then is that you might allow each of the site, vhost, list, and user to define their own thresholds above which the message would be considered spam. Certainly, header regexp matching is very doable, although we have to be careful of giving this control to the users. First, evil regexps can be constructed that can tank performance. Second, regexps are incomprehensible to most non-programmers (and many programmers too!). > You'd then want to convert those numbers to, say, a spamicity percentage. Note that the ASRG is working on some standards in this area, and though I'm on the list I haven't been paying very close attention to it. In general, if standards are established, Mailman should grok them. > We should allow people to get as much spam as they want. We should let them > choose low thresholds, but not so low that they miss a lot of genuine > posts, and maybe there should be no spam filtering on closed lists at all. OTOH, we have to decide how much spam defenses should be built into Mailman. Certainly I believe the MTA should be doing a huge amount (if not most) of the spam filtering before it even gets to Mailman. Where Mailman and list admins need to get into the act is in the murky "unsure" area, where for example, a message may or may not be spam to a site-wide filter, but would definitely be on or off topic for a particular list. -Barry From barry at python.org Thu Apr 8 20:58:17 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 8 20:58:23 2004 Subject: [Mailman3-dev] Feature request In-Reply-To: <01c401c40b9d$775bea60$1048a8c0@rupt> References: <01c401c40b9d$775bea60$1048a8c0@rupt> Message-ID: <1081472296.5071.35.camel@anthem.wooz.org> On Tue, 2004-03-16 at 16:27, Jordan Hayes wrote: > I'd like a more flexible way to deal with the mbox file; I run a list > that has several years of archives, and if I left all the postings in a > single mbox file, it would be over 1GB ... which means it would get > backed up nightly :-) > > What I do now is once per year trim it down, move the generated archives > somewhere safe, and start over. I'd like a way to rotate the mbox file > like I do the archives. So, Mailman3 will have a message store, which will, in general be how things like the archives, admindb, and new access methods will get the data from. I think Chuq's old idea that archives should be generated on the fly is one that has a lot of merit. The question then is whether we need an mbox file. I still think we do need to provide the option of a raw on-disk storage. I personally hate Unix mbox format, but a small elaboration like mmdf format is better. I don't care about huge mbox files personally, although I can understand the concern. I don't know enough about the details of MH format, but maybe that'd be an option. The criteria to me are: 1) don't invent a format, 2) that there be Python support for whatever we choose, i.e.: http://www.python.org/doc/current/lib/module-mailbox.html -Barry From barry at python.org Thu Apr 8 21:08:40 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 8 21:08:49 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: <2147483647.1079453528@beeding.central.susx.ac.uk> References: <200403152131.i2FLVhru027496@agora.fsl.cs.sunysb.edu> <1079386937.5149.283.camel@anthem.wooz.org> <2147483647.1079444330@beeding.central.susx.ac.uk> <1079447811.10434.38.camel@anthem.wooz.org> <2147483647.1079453528@beeding.central.susx.ac.uk> Message-ID: <1081472919.5071.47.camel@anthem.wooz.org> On Tue, 2004-03-16 at 11:12, Ian A B Eiloart wrote: > > The way I've been thinking about it ties back to the roster notion. > > Rosters may be tied via conduits to a back-end storage, and each storage > > would have its own policies for reading and writing. > > Well, if a roster is a membership list which can be included in another > membership list, then that's OK. > > I need to have rosters with heterogeneous membership though. Some members > from one conduit, and others from another. > > And, I want mailman to be able to tie "sussex.ac.uk" email addresses to a > particular conduit. My read only LDAP conduit as it happens. I don't want > people in that domain (or susx.ac.uk) to be able to register through > another conduit. > > Further, I want some lists to be tied to a specific conduit. I don't want > people subcribing to "staff@sussex.ac.uk" unless they have a sussex email > address. We've changed our thinking about this stuff post-sprint. Currently we're thinking that any magic tying of members to backends happens in the implementation of the IUserStorage interface. To Mailman, there's one place to get and add users and the implementation handles any necessary magic. I think that's the only way to maintain our sanity. One bone to throw at this is that the interface for creating new users is passed a 'domain' argument that a backend could use to select where to store the new user data. The domain will likely be the internal tag for a virtual domain (e.g. for a web request coming to mail.python.org or an email to python.org, the tag would be 'python' -- but this is completely configurable by the site admin). The implementation should be able to raise a CantCreateUserError or some such if the backend is adapting to a read-only storage. > Regarding rosters: I'd like to be able to fetch rosters with SQL queries > from a separate database. So, I want to populate lists from ORACLE, but > then get email addresses for each list member from LDAP, and when users log > in, I want to authenticate against the LDAP database. I think this is a valid use case and we're going to have to see if the interfaces we're currently defining will allow you to do this kind of thing. I'm going to have a lot of friction against exposing anything like SQL external into the application (i.e. above the set of interfaces). -Barry From barry at python.org Thu Apr 8 21:01:41 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 8 21:19:04 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: <2147483647.1079447849@beeding.central.susx.ac.uk> References: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> <1079387385.5149.292.camel@anthem.wooz.org> <2147483647.1079447849@beeding.central.susx.ac.uk> Message-ID: <1081472500.5071.39.camel@anthem.wooz.org> On Tue, 2004-03-16 at 09:37, Ian A B Eiloart wrote: > Hmm, I need to define some list styles for in house use, and put together > some documentation on how to configure a list to a style. I may even make > some scripts to convert a list to a particular style. > > Is there a list of styles out there that I could get started with? Is there > any documentation on how best to configure mailman certain types of list? Nope, and nope, because we're mostly just musing here. There's no direct support for this in MM2, and the feature is only half-baked in MM3. > Actually, I'm not so sure a *list* style is what I need. Here are some > dimensions that I need to apply styles in: Composability is probably an important concept for list styles. -Barry From claw at kanga.nu Thu Apr 8 21:20:51 2004 From: claw at kanga.nu (J C Lawrence) Date: Thu Apr 8 21:20:56 2004 Subject: [Mailman3-dev] Threaded moderation interface In-Reply-To: Message from Barry Warsaw of "Thu, 08 Apr 2004 20:46:00 EDT." <1081471560.5071.22.camel@anthem.wooz.org> References: <6623.1080885769@kanga.nu> <1081471560.5071.22.camel@anthem.wooz.org> Message-ID: <19414.1081473651@kanga.nu> On Thu, 08 Apr 2004 20:46:00 -0400 Barry Warsaw wrote: > On Fri, 2004-04-02 at 01:02, J C Lawrence wrote: >> I'd like a view of the moderation interface that displays held >> messages in terms of threads, and allows action on both individual >> messages and entire threads. > Most of the lists I admin probably wouldn't benefit much from a > threaded moderation interface, but I can see where it would be useful > for some lists. Aye, there's a particularly interesting case (for me) in lists which don't munge Reply-To: where the moderator can/could watch a thread develop off-list and them approve the whole thing once it has started rolling. > OTOH, what I /really/ want is access to the admindb through a real > mail client, i.e. IMAP. Hurm, that could be interesting. > I'm personally just not a big fan of rendering email in HTML for a lot > of reasons... I'm finding that this problem space is rapidly turning multi-protocol where SMTP is but one of the many possible, and plain text or HTML are but possible rendering models. I've got this idea for a well formed XML DTD for email payloads that properly handles quotes, attributions, attachments... > ... , so it should /at least/ be possible to interact with a mailing > list with real mail readers. There's also the whole thing about command and control via email messages. >> Among other things this would allow easier "best-of" list operation. > I'm not sure I follow. Could you explain what you mean? Imagine two lists, one subscribed to the other. The child list is moderated and holds all messages for moderation. The first list has fairly heavy discussion. Periodically, after thread death, the moderator reviews the threads and picks out those he thought most valuable (mebe there's a vote) and posts them to the child list. As such the child list then becomes the "best of parent list" list. -- 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 Thu Apr 8 22:48:47 2004 From: claw at kanga.nu (J C Lawrence) Date: Thu Apr 8 22:48:51 2004 Subject: [Mailman3-dev] Feature request In-Reply-To: Message from Barry Warsaw of "Thu, 08 Apr 2004 20:58:17 EDT." <1081472296.5071.35.camel@anthem.wooz.org> References: <01c401c40b9d$775bea60$1048a8c0@rupt> <1081472296.5071.35.camel@anthem.wooz.org> Message-ID: <21534.1081478927@kanga.nu> On Thu, 08 Apr 2004 20:58:17 -0400 Barry Warsaw wrote: > I don't know enough about the details of MH format, but maybe that'd > be an option. The criteria to me are: 1) don't invent a format, 2) > that there be Python support for whatever we choose, i.e.: > http://www.python.org/doc/current/lib/module-mailbox.html MH folders are triviality itself: One file per message. File names are digit strings, incrementing with each new message. It is, literally, that simple. MH then adds various layering concepts like sequences files, but in general they don't apply to Mailman's interests (they essentially provide things like seen/unseen and abstracted views). -- 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 dev at elevatorup.com Fri Apr 9 08:48:16 2004 From: dev at elevatorup.com (Aaron Schaap) Date: Fri Apr 9 08:48:37 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: <1081471284.5071.15.camel@anthem.wooz.org> Message-ID: > That's not a bad idea. Editing CSS should be harmless, right? I mean > is there the equivalent of cross-site scripting exploits possible if all > you give is the ability to edit CSS? Using CSS is probably the safest and easiest way. No exploits that I know of. If anything, someone can even write up their own look and feel that could over ride a list look but it would only be viewable that person's browser. Put something like and allow a user (if they wanted too) to change anything for their liking. Other issues however come about - What if a person wants to add a whole navigation system, or what if they need to add some JavaScript. Maybe, we could just allow a header and footer to be editable and let people use CSS for everything else. ------------------------- Aaron Schaap Elevator Up - Internet Consulting & Development Phone: 616-566-1423 Web: www.elevatorup.com Email: aaron.schaap@elevatorup.com From barry at python.org Fri Apr 9 09:16:16 2004 From: barry at python.org (Barry Warsaw) Date: Fri Apr 9 09:16:22 2004 Subject: [Mailman3-dev] Feature request In-Reply-To: <21534.1081478927@kanga.nu> References: <01c401c40b9d$775bea60$1048a8c0@rupt> <1081472296.5071.35.camel@anthem.wooz.org> <21534.1081478927@kanga.nu> Message-ID: <1081516575.5071.135.camel@anthem.wooz.org> On Thu, 2004-04-08 at 22:48, J C Lawrence wrote: > MH folders are triviality itself: > > One file per message. > > File names are digit strings, incrementing with each new message. > > It is, literally, that simple. :) > MH then adds various layering concepts like sequences files, but in > general they don't apply to Mailman's interests (they essentially > provide things like seen/unseen and abstracted views). I wonder if we'd need sequence files if say, we wanted to repopulate a date-indexed archive thread. OTOH, the magical mystical message store probably ought to not care in what order the messages are fed to it (if say, we wanted to blow away an archive and rebuild it from scratch). -Barry From barry at python.org Fri Apr 9 09:21:53 2004 From: barry at python.org (Barry Warsaw) Date: Fri Apr 9 09:21:58 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: References: Message-ID: <1081516912.5071.141.camel@anthem.wooz.org> On Fri, 2004-04-09 at 08:48, Aaron Schaap wrote: > Using CSS is probably the safest and easiest way. No exploits that I know > of. If anything, someone can even write up their own look and feel that > could over ride a list look but it would only be viewable that person's > browser. That's fine. If a list admin does something dumb, that's fine as long as they can undo the breakage. > Put something like and allow a user (if they > wanted too) to change anything for their liking. > > Other issues however come about - What if a person wants to add a whole > navigation system, or what if they need to add some JavaScript. Maybe, we > could just allow a header and footer to be editable and let people use CSS > for everything else. We're definitely looking for the 80/20 solution here. If someone wants infinite thru-the-web editability of Mailman's web interface, they can use the Zope-fronted Mailman approach. Or they could just edit the template files from the command line (hard to do now because we spread the u/i across 2.5 different rendering systems). I think a lot of people would be happy with a sufficiently flexible CSS model and the ability to edit the CSS through the web. What do y'all think? -Barry From barry at python.org Fri Apr 9 09:29:17 2004 From: barry at python.org (Barry Warsaw) Date: Fri Apr 9 09:29:24 2004 Subject: [Mailman3-dev] Threaded moderation interface In-Reply-To: <19414.1081473651@kanga.nu> References: <6623.1080885769@kanga.nu> <1081471560.5071.22.camel@anthem.wooz.org> <19414.1081473651@kanga.nu> Message-ID: <1081517357.5071.147.camel@anthem.wooz.org> On Thu, 2004-04-08 at 21:20, J C Lawrence wrote: > Aye, there's a particularly interesting case (for me) in lists which > don't munge Reply-To: where the moderator can/could watch a thread > develop off-list and them approve the whole thing once it has started > rolling. > > > OTOH, what I /really/ want is access to the admindb through a real > > mail client, i.e. IMAP. > > Hurm, that could be interesting. The wild-ass idea is that you could view the thread in your mail reader, and then just move the whole thing to the Approved folder. Mailman would pick that up occasionally and post those messages. > > I'm personally just not a big fan of rendering email in HTML for a lot > > of reasons... > > I'm finding that this problem space is rapidly turning multi-protocol > where SMTP is but one of the many possible, and plain text or HTML are > but possible rendering models. I've got this idea for a well formed XML > DTD for email payloads that properly handles quotes, attributions, > attachments... Yep, that's definitely the road I'm thinking about. Although I hate to write XML (it's really not human friendly), there are definitely some interesting things you can do with email once it's in that format. You might want to experiment with a new type of Generator for the object model that the email package creates. > Imagine two lists, one subscribed to the other. The child list is > moderated and holds all messages for moderation. The first list has > fairly heavy discussion. Periodically, after thread death, the > moderator reviews the threads and picks out those he thought most > valuable (mebe there's a vote) and posts them to the child list. As > such the child list then becomes the "best of parent list" list. That's a neat idea -- please add it to the wiki! -Barry From claw at kanga.nu Fri Apr 9 09:30:45 2004 From: claw at kanga.nu (J C Lawrence) Date: Fri Apr 9 09:30:50 2004 Subject: [Mailman3-dev] Feature request In-Reply-To: Message from Barry Warsaw of "Fri, 09 Apr 2004 09:16:16 EDT." <1081516575.5071.135.camel@anthem.wooz.org> References: <01c401c40b9d$775bea60$1048a8c0@rupt> <1081472296.5071.35.camel@anthem.wooz.org> <21534.1081478927@kanga.nu> <1081516575.5071.135.camel@anthem.wooz.org> Message-ID: <4747.1081517445@kanga.nu> On Fri, 09 Apr 2004 09:16:16 -0400 Barry Warsaw wrote: > On Thu, 2004-04-08 at 22:48, J C Lawrence wrote: >> MH then adds various layering concepts like sequences files, but in >> general they don't apply to Mailman's interests (they essentially >> provide things like seen/unseen and abstracted views). > I wonder if we'd need sequence files if say, we wanted to repopulate a > date-indexed archive thread. OTOH, the magical mystical message store > probably ought to not care in what order the messages are fed to it > (if say, we wanted to blow away an archive and rebuild it from > scratch). Don't bother. MH isn't a transport, its a storage format albeit a rather nice one. If you want indexes, do your own. Now, harking back to earlier conversations: Stick NNTP on top of it... -- 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 mlm at kaibren.com Fri Apr 9 09:48:31 2004 From: mlm at kaibren.com (MLM Subscriber) Date: Fri Apr 9 09:48:34 2004 Subject: [Mailman3-dev] Threaded moderation interface In-Reply-To: <1081517357.5071.147.camel@anthem.wooz.org> References: <6623.1080885769@kanga.nu> <1081471560.5071.22.camel@anthem.wooz.org> <19414.1081473651@kanga.nu> <1081517357.5071.147.camel@anthem.wooz.org> Message-ID: <6.0.3.0.2.20040409093737.02fb9d48@localhost> On Thu, 2004-04-08 at 21:20, J C Lawrence wrote: >The wild-ass idea is that you could view the thread in your mail reader, >and then just move the whole thing to the Approved folder. Mailman >would pick that up occasionally and post those messages. There can't be an entire thread for approval until the first message is approved. OTOH- I suppose this might be real useful when a thread gets started but gets out of hand. At some point the admin could simply reject all new messages to the thread until it calms down. This leads to another thread based idea... If mm3 becomes thread aware, can't we switch individual threads between moderated and unmoderated to control flames without moderating the entire list? -mb From barry at python.org Fri Apr 9 09:48:40 2004 From: barry at python.org (Barry Warsaw) Date: Fri Apr 9 09:48:49 2004 Subject: [Mailman3-dev] Feature request In-Reply-To: <4747.1081517445@kanga.nu> References: <01c401c40b9d$775bea60$1048a8c0@rupt> <1081472296.5071.35.camel@anthem.wooz.org> <21534.1081478927@kanga.nu> <1081516575.5071.135.camel@anthem.wooz.org> <4747.1081517445@kanga.nu> Message-ID: <1081518520.5071.153.camel@anthem.wooz.org> On Fri, 2004-04-09 at 09:30, J C Lawrence wrote: > On Fri, 09 Apr 2004 09:16:16 -0400 > Barry Warsaw wrote: > > On Thu, 2004-04-08 at 22:48, J C Lawrence wrote: > > >> MH then adds various layering concepts like sequences files, but in > >> general they don't apply to Mailman's interests (they essentially > >> provide things like seen/unseen and abstracted views). > > > I wonder if we'd need sequence files if say, we wanted to repopulate a > > date-indexed archive thread. OTOH, the magical mystical message store > > probably ought to not care in what order the messages are fed to it > > (if say, we wanted to blow away an archive and rebuild it from > > scratch). > > Don't bother. MH isn't a transport, its a storage format albeit a > rather nice one. If you want indexes, do your own. > > Now, harking back to earlier conversations: Stick NNTP on top of it... +1! -Barry From mlm at kaibren.com Fri Apr 9 13:01:06 2004 From: mlm at kaibren.com (MLM Subscriber) Date: Fri Apr 9 13:01:22 2004 Subject: [Mailman3-dev] Include real name in Roster view In-Reply-To: <1081174640.29721.21.camel@anthem.wooz.org> References: <6.0.3.0.2.20040404171006.03020ec0@localhost> <1081174640.29721.21.camel@anthem.wooz.org> Message-ID: <6.0.3.0.2.20040409124016.02eed940@localhost> At 10:17 AM 4/5/2004, Barry Warsaw wrote: >On Sun, 2004-04-04 at 17:13, MLM Subscriber wrote: > > In mailman 2, I created a patch so the roster view (from the listinfo > page) > > shows real names as well as (obfuscated or actual) email addresses. > >I think that's a good idea, but we need to rethink the u/i for roster >views (and membership access in general). The current approach doesn't >scale when you have something like 200k addresses in your list. > > > This should be a supported option in MM3. Ideally there would be a config > > attribute similar to the "Obscure addresses" attribute for listing > > fullnames in the roster views. (I am tired of having to reapply the patch > > for each release. Can I get it added to the mm2 tree?) > >Did you post your patch to SourceForge? Patch was posted today. Yes - views of large rosters would be aided by the sublist and search capabilities that are found on the current membership management pages. Speaking of fullname, how about adding a "required" option for the full name field in the enrollment system? If the fullname is not included in an email request for membership, send the requester to the web interface rather than accept partial information. The "required" attribute could be applied similarly to other member attributes it the list was so configured. -mb From mark at pdc-racing.net Fri Apr 9 13:04:41 2004 From: mark at pdc-racing.net (Mark Dadgar) Date: Fri Apr 9 13:04:49 2004 Subject: [Mailman3-dev] Include real name in Roster view In-Reply-To: <6.0.3.0.2.20040409124016.02eed940@localhost> References: <6.0.3.0.2.20040404171006.03020ec0@localhost> <1081174640.29721.21.camel@anthem.wooz.org> <6.0.3.0.2.20040409124016.02eed940@localhost> Message-ID: On Apr 9, 2004, at 10:01 AM, MLM Subscriber wrote: > Speaking of fullname, how about adding a "required" option for the > full name field in the enrollment system? If the fullname is not > included in an email request for membership, send the requester to the > web interface rather than accept partial information. The "required" > attribute could be applied similarly to other member attributes it the > list was so configured. YES PLEASE. - Mark ----- mark@pdc-racing.net From mk2s at digitalcommute.com Sat Apr 10 12:31:19 2004 From: mk2s at digitalcommute.com (Michael Kato) Date: Sat Apr 10 12:32:22 2004 Subject: [Mailman3-dev] getting mm3 running on mac OSX 10.3 (or at least the tests) Message-ID: <7EDF36B8-8B0C-11D8-AD3E-000A95AB83D2@digitalcommute.com> I did the following to get mm3 to at least run tests on OS X. run the getstuff.sh script by hand. pyprotocol, Zconfig, zope should install fine. Twisted 1.2 needed the following patch/modifications in setup.py to install. --- setup.py.orig Sat Apr 10 12:18:32 2004 +++ setup.py Sat Apr 10 12:07:39 2004 @@ -184,7 +184,7 @@ exts.append( Extension("twisted.internet.cfsupport", ["twisted/internet/cfsupport/cfsupport.c"], extra_compile_args=['-w'], - extra_link_args=['-framework','CoreFoundation','- framework','CoreServices','-framework','Carbon'], + extra_link_args=['-framework','CoreFoundation','- framework','CoreServices','-framework','Carbon','-framework','System'], define_macros=define_macros)) self.extensions.extend(exts) Once installed there's the problem that OS X python doesn't have bsddb support, at least it didn't find _bsddb to import. I develop on a PowerBook ssh to a fedora/intel box so I'll occasionally test against OS X as I make progress. I expect the MySQL stuff to run without issues. ....maki.... From mk2s at digitalcommute.com Sat Apr 10 12:44:31 2004 From: mk2s at digitalcommute.com (Michael Kato) Date: Sat Apr 10 12:44:33 2004 Subject: [Mailman3-dev] common tests for all backends(can I move'm to mailman/tests)? Message-ID: <575AE2C2-8B0E-11D8-AD3E-000A95AB83D2@digitalcommute.com> Barry, I know you've probably already thought of this, but would it be ok to move tests that are common across backends into mailman/tests? I mean can I yank tests out of some of the test cases in berkeleydb/tests and place them into mailman/tests? Such as those that are common to all backends like create_user etc. I'm also considering making it so that test.py also takes a list of backends to test(any better ideas?) Ideally I'd like the common tests to be run once for each backend. For instance, on the Mac OS X, I'm having trouble testing berkleydb because python on the mac seems not to have bsddb support. (I may look further into this...) But in any case, I think it would be nice to only test the backends and other things that are of interest when running test.py ....maki.... PS, what do you think of collecting all of the backend implementations into on directory? From Dale at Newfield.org Sat Apr 10 15:20:41 2004 From: Dale at Newfield.org (Dale Newfield) Date: Sat Apr 10 15:20:57 2004 Subject: [Mailman3-dev] getting mm3 running on mac OSX 10.3 (or at least the tests) In-Reply-To: <7EDF36B8-8B0C-11D8-AD3E-000A95AB83D2@digitalcommute.com> References: <7EDF36B8-8B0C-11D8-AD3E-000A95AB83D2@digitalcommute.com> Message-ID: On Sat, 10 Apr 2004, Michael Kato wrote: > Twisted 1.2 needed the following patch/modifications in setup.py to > install. I didn't have problems with that, but I needed this patch in setup.py (for mailman) to get it to compile: 61,62c61,62 < Extension("zope.interface._zope_interface_ospec", < ["src/zope/interface/_zope_interface_ospec.c"]), --- > Extension("zope.interface._zope_interface_coptimizations", > ["src/zope/interface/_zope_interface_coptimizations.c"]), I'm not even sure this makes sense, but with that change it did compile. > Once installed there's the problem that OS X python doesn't have bsddb > support, at least it didn't find _bsddb to import. I am getting that same error, and of course will investigate, but I've yet to do so. I am having lots of problems with the unit tests, though, and I'm realizing it's been a long time since I really did much with Python :-) After a bit more investigation, I realize that a number of the tests are failing due to incomplete sets of namespace changes. (I'll include one example below, so someone can tell me if I'm going completely off course, please!) It seems silly to waste more people's time here than necessary, so maybe this is where it benefits us to start letting more people commit changes to CVS. (I'm betting Maki had to take the time to make these same changes, because it wasn't until I'd made them that I first got the "No module named _bsddb" error.) Barry? RCS file: /cvsroot/mailman/mailman3/src/mailman/berkeleydb/tests/test_members.py,v retrieving revision 3.0 diff -r3.0 test_members.py 28,31c28,31 < from mailman.interfaces.members import IPreferences, IDeliveryStatus < from mailman.interfaces.members import IBounceInfo < from mailman.interfaces.members import DeliveryMode, DeliveryStatus < from mailman.database.bdbmembers import BDBMembers --- > from mailman.interfaces.users import IPreferences, IDeliveryStatus > from mailman.interfaces.users import IBounceInfo > from mailman.interfaces.users import DeliveryMode, DeliveryStatus > from mailman.berkeleydb.bdbuser import BDBUserDatabase 41c41 < self._db = BDBMembers(os.path.join(VARDIR, 'members.db')) --- > self._db = BDBUserDatabase(os.path.join(VARDIR, 'members.db')) 111c111 < self._db = BDBMembers(os.path.join(VARDIR, 'members.db')) --- > self._db = BDBUserDatabase(os.path.join(VARDIR, 'members.db')) From Dale at Newfield.org Sat Apr 10 15:25:25 2004 From: Dale at Newfield.org (Dale Newfield) Date: Sat Apr 10 15:25:39 2004 Subject: [Mailman3-dev] common tests for all backends(can I move'm to mailman/tests)? In-Reply-To: <575AE2C2-8B0E-11D8-AD3E-000A95AB83D2@digitalcommute.com> References: <575AE2C2-8B0E-11D8-AD3E-000A95AB83D2@digitalcommute.com> Message-ID: On Sat, 10 Apr 2004, Michael Kato wrote: > PS, what do you think of collecting all of the backend implementations > into on directory? +1 -Dale From carbonnb at sympatico.ca Fri Apr 9 10:23:33 2004 From: carbonnb at sympatico.ca (Bryan Carbonnell) Date: Sun Apr 11 11:25:39 2004 Subject: [Mailman3-dev] Mailman Design Message-ID: <407679A5.5227.2424C2@localhost> On 9 Apr 2004 at 9:21, Barry Warsaw wrote: > We're definitely looking for the 80/20 solution here. If someone > wants infinite thru-the-web editability of Mailman's web interface, > they can use the Zope-fronted Mailman approach. Or they could just > edit the template files from the command line (hard to do now > because we spread the u/i across 2.5 different rendering systems). > I think a lot of people would be happy with a sufficiently flexible > CSS model and the ability to edit the CSS through the web. > > What do y'all think? I think that most people would be sufficiently happy with just CSS editing. But given the choice, I, Personally, would prefer to be able to edit both the CSS and the HTML. Right now I'm trying to get my MM interface to look like the main site, you can see a mock up at http://databaseadvisors.com/~bryan/ I don't think the menu system to the right would be possible to add strictly with CSS editing ability only. -- Bryan Carbonnell - carbonnb@sympatico.ca On the keyboard of life, always keep one finger on the escape key. -- Bryan Carbonnell - carbonnb@sympatico.ca Tell me what you need, and I'll tell you how to get along without it. From claw at kanga.nu Sun Apr 11 12:53:30 2004 From: claw at kanga.nu (J C Lawrence) Date: Sun Apr 11 12:53:37 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: Message from "Bryan Carbonnell" of "Fri, 09 Apr 2004 10:23:33 EDT." <407679A5.5227.2424C2@localhost> References: <407679A5.5227.2424C2@localhost> Message-ID: <489.1081702410@kanga.nu> On Fri, 09 Apr 2004 10:23:33 -0400 Bryan Carbonnell wrote: > Right now I'm trying to get my MM interface to look like the main > site, you can see a mock up at http://databaseadvisors.com/~bryan/ I > don't think the menu system to the right would be possible to add > strictly with CSS editing ability only. Have a look at CSS/Edge for examples of how that could be done with CSS. -- 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 jmhayes at speakeasy.net Sun Apr 11 13:10:27 2004 From: jmhayes at speakeasy.net (Jordan Hayes) Date: Sun Apr 11 13:10:31 2004 Subject: [Mailman3-dev] Mailman Design References: <407679A5.5227.2424C2@localhost> Message-ID: <097301c41fe7$e319c5c0$1048a8c0@rupt> > I, Personally, would prefer to be able to edit > both the CSS and the HTML. Me, too. I added support for SWISH-E and Google ads via the templates to a list I run: http://mailman.lbo-talk.org/ Take a look at the postings. /jordan From dev at elevatorup.com Sun Apr 11 15:48:08 2004 From: dev at elevatorup.com (Aaron Schaap) Date: Sun Apr 11 15:48:26 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: <407679A5.5227.2424C2@localhost> Message-ID: > But given the choice, I, Personally, would prefer to be able to edit > both the CSS and the HTML. > > Right now I'm trying to get my MM interface to look like the main > site, you can see a mock up at http://databaseadvisors.com/~bryan/ I > don't think the menu system to the right would be possible to add > strictly with CSS editing ability only. The idea would be - create the site with compliant XHTML and CSS. Use CSS for all design but allow people to still change various things in the HTML. For example - if people could simply add a header and footer only. You would still be able to do quite a bit. Especially adding that navigation. To move things around within the Mailman (like forms, logos, etc...) you would simply edit the CSS. I personally feel this is the simplest way to implement design changes. Right now you are allowed to edit the HTML and move the Mailman Templating Language around. Side note for Brian: ------------------------ Try structuring your navigation using nested unordered lists. Example:
  • link 1
  • link 2
  • link 3
    • sublink
    • sublink
  • link 5
  • link 6
------------------------- Aaron Schaap Elevator Up - Internet Consulting & Development Phone: 616-566-1423 Web: www.elevatorup.com Email: aaron.schaap@elevatorup.com From mk2s at digitalcommute.com Sun Apr 11 21:14:45 2004 From: mk2s at digitalcommute.com (Michael Kato) Date: Sun Apr 11 21:14:46 2004 Subject: [Mailman3-dev] getting mm3 running on mac OSX 10.3 (or... Message-ID: Dale, I've changed one file(mailman/categories/tests/test_xmlstring) so that it doesn't fail the tests. I've mostly been ignoring the tests that fail in berkleydb/tests as it seems to be based on really old code. As well as tests/test_lock.py as it seems to be testing lock.py which is not referenced anywhere else. As for getting the stubbackend/tests working on OS X you'll have to comment out backendtest.conf as in: Index: etc/backendtest.conf =================================================================== RCS file: /cvsroot/mailman/mailman3/etc/backendtest.conf,v retrieving revision 1.2 diff -u -r1.2 backendtest.conf --- etc/backendtest.conf 6 Apr 2004 04:14:01 -0000 1.2 +++ etc/backendtest.conf 12 Apr 2004 00:29:00 -0000 @@ -3,13 +3,13 @@ %include defines.conf - - path $vardir/listdb - - - - path $vardir/userdb - +# +# path $vardir/listdb +# + +# +# path $vardir/userdb +# ....maki.... From mk2s at digitalcommute.com Sun Apr 11 21:43:08 2004 From: mk2s at digitalcommute.com (Michael Kato) Date: Sun Apr 11 21:43:12 2004 Subject: [Mailman3-dev] found bsddb for OS X 10.3 Message-ID: After a bit of digging(bit more than I expected) I found a site that has the missing _bsddb file with statically linked BerkleyDB 4.1.25 at: http://undefined.org/python/pimp/ Follow the instructions at the top of the page. And I was able to get some of my tests to run against a bsddb backend. Nifty. ....maki.... From claw at kanga.nu Sun Apr 11 23:11:48 2004 From: claw at kanga.nu (J C Lawrence) Date: Sun Apr 11 23:11:52 2004 Subject: [Mailman3-dev] Threaded moderation interface In-Reply-To: Message from Barry Warsaw of "Fri, 09 Apr 2004 09:29:17 EDT." <1081517357.5071.147.camel@anthem.wooz.org> References: <6623.1080885769@kanga.nu> <1081471560.5071.22.camel@anthem.wooz.org> <19414.1081473651@kanga.nu> <1081517357.5071.147.camel@anthem.wooz.org> Message-ID: <10899.1081739508@kanga.nu> On Fri, 09 Apr 2004 09:29:17 -0400 Barry Warsaw wrote: > On Thu, 2004-04-08 at 21:20, J C Lawrence wrote: >> Imagine two lists, one subscribed to the other. The child list is >> moderated and holds all messages for moderation. The first list has >> fairly heavy discussion. Periodically, after thread death, the >> moderator reviews the threads and picks out those he thought most >> valuable (mebe there's a vote) and posts them to the child list. As >> such the child list then becomes the "best of parent list" list. > That's a neat idea -- please add it to the wiki! Done: http://zope.org/Members/bwarsaw/MailmanDesignNotes/FeaturesWeWantToSupport -- 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 mk2s at digitalcommute.com Mon Apr 12 00:10:45 2004 From: mk2s at digitalcommute.com (Michael Kato) Date: Mon Apr 12 00:10:49 2004 Subject: [Mailman3-dev] getting webserver to run with stubbackend; how about ITransactionManager.checkState()? Message-ID: <5F2FA0E4-8C37-11D8-B4DD-000A95AB83D2@digitalcommute.com> Barry, I came across the following code, and thought perhaps the ITransactionManager interface should support a method like checkState() then the following code can be changed to use that instead. What do you think? ....maki.... Index: bin/webserver =================================================================== RCS file: /cvsroot/mailman/mailman3/bin/webserver,v retrieving revision 3.0 diff -u -r3.0 webserver --- bin/webserver 29 Mar 2004 05:18:49 -0000 3.0 +++ bin/webserver 12 Apr 2004 03:53:10 -0000 @@ -104,8 +104,10 @@ else: if txnlist: txnlist.commit() if txnuser: txnuser.commit() - assert not dbmgr.lists._txnstack(), 'listdb: %s' % listdb._txnstack() - assert not dbmgr.users._txnstack(), 'userdb: %s' % userdb._txnstack() + # ITransactionManager perhaps should define stateCheck as a + # public method + #assert not dbmgr.lists._txnstack(), 'listdb: %s' % listdb._txnstack() + #assert not dbmgr.users._txnstack(), 'userdb: %s' % userdb._txnstack() if utext is None: return # All do_ methods return unicode strings, as is the default for all From carbonnb at sympatico.ca Mon Apr 12 09:56:13 2004 From: carbonnb at sympatico.ca (Bryan Carbonnell) Date: Mon Apr 12 09:56:19 2004 Subject: [Mailman3-dev] Mailman Design Message-ID: <407A67BD.4517.1A5388@localhost> On 11 Apr 2004 at 12:53, J C Lawrence wrote: > On Fri, 09 Apr 2004 10:23:33 -0400 > Bryan Carbonnell wrote: > > > Right now I'm trying to get my MM interface to look like the main > > site, you can see a mock up at http://databaseadvisors.com/~bryan/ > > I don't think the menu system to the right would be possible to > > add strictly with CSS editing ability only. > > Have a look at CSS/Edge for examples of how that could be done with > CSS. CSS editing is great for layout of content that is already in the HTML templates. I'm talking about adding actual content into the templates. Specifically adding my site's navigation to the MM interface and possibly customising it depending on where the user / admin is in the interface. -- Bryan Carbonnell - carbonnb@sympatico.ca Age is a very high price to pay for maturity. -- Bryan Carbonnell - carbonnb@sympatico.ca We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true.^ [Robert Wilensky (1997)] From carbonnb at sympatico.ca Mon Apr 12 10:06:25 2004 From: carbonnb at sympatico.ca (Bryan Carbonnell) Date: Mon Apr 12 10:06:31 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: References: <407679A5.5227.2424C2@localhost> Message-ID: <407A6A21.6260.23AA14@localhost> On 11 Apr 2004 at 15:48, Aaron Schaap wrote: > The idea would be - create the site with compliant XHTML and CSS. Use > CSS for all design but allow people to still change various things in > the HTML. > > For example - if people could simply add a header and footer only. You > would still be able to do quite a bit. Especially adding that > navigation. > > To move things around within the Mailman (like forms, logos, etc...) > you would simply edit the CSS. > > I personally feel this is the simplest way to implement design > changes. But if the HTML and the CSS are separate then Barry and the MM dev team could concentrate on getting the code working and the design team, which I think there are a couple of folks that have expressed an interest, can concentrate on the web UI stuff. As well, down the road, when someone new comes along and wants to "freshen up" the MM interface, it's just a case of changing the HTML templates and the CSS. All they need to know is HTML and CSS to make those design changes. > Right now you are allowed to edit the HTML and move the Mailman > Templating Language around. Not all of it. I've spent the last couple of weeks trying to work out how to change the listinfo page. It's all hard coded into the MM source :( -- Bryan Carbonnell - carbonnb@sympatico.ca Artificial intelligence is no match for natural stupidity. From claw at kanga.nu Mon Apr 12 13:42:24 2004 From: claw at kanga.nu (J C Lawrence) Date: Mon Apr 12 13:42:30 2004 Subject: [Mailman3-dev] Feature request: saturation MTA injection Message-ID: <9286.1081791744@kanga.nu> A lot of MLM MTA tuning comes down to handling the spool most efficiently, and that is often more easily handled/optimised in the cases where the spool is fat/large rather than when it is nearly empty. VERP exacerbates this problem. Request: The queue runner, when handling MTA injection, forks up to N instances/threads, where N <= RCPT TO blocks and N <= a value configured in mm_cfg.py. The goal is most rapid injection of the list broadcast into the spool. This is particularly valuable for large moderated lists. -- 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 Mon Apr 19 07:36:52 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Mon Apr 19 07:37:03 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: <1081472500.5071.39.camel@anthem.wooz.org> References: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> <1079387385.5149.292.camel@anthem.wooz.org> <2147483647.1079447849@beeding.central.susx.ac.uk> <1081472500.5071.39.camel@anthem.wooz.org> Message-ID: <2147483647.1082378212@beeding.central.susx.ac.uk> > Composability is probably an important concept for list styles. > > -Barry > What's that? -- Ian Eiloart Servers Team Sussex University ITS From iane at sussex.ac.uk Mon Apr 19 07:47:03 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Mon Apr 19 07:47:06 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: <407679A5.5227.2424C2@localhost> References: <407679A5.5227.2424C2@localhost> Message-ID: <2147483647.1082378823@beeding.central.susx.ac.uk> I need to be able to do all this: Add headers and footers, to all pages, to match our in house style. Modify text - for example, to point people at our terms of use. Change CSS, again to match our in house style. -- Ian Eiloart Servers Team Sussex University ITS From barry at python.org Mon Apr 19 10:58:53 2004 From: barry at python.org (Barry Warsaw) Date: Mon Apr 19 10:59:19 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: <2147483647.1082378212@beeding.central.susx.ac.uk> References: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> <1079387385.5149.292.camel@anthem.wooz.org> <2147483647.1079447849@beeding.central.susx.ac.uk> <1081472500.5071.39.camel@anthem.wooz.org> <2147483647.1082378212@beeding.central.susx.ac.uk> Message-ID: <1082386733.7365.104.camel@anthem.wooz.org> On Mon, 2004-04-19 at 07:36, Ian A B Eiloart wrote: > > Composability is probably an important concept for list styles. > > > > -Barry > > > > What's that? The idea that you might have a "privacy" sub-style and a "bounces" sub-style. Each would affect only a handful of list configuration variables. You'd like to be able to combine them into super-styles that would affect the union of those variables. -Barry From iane at sussex.ac.uk Mon Apr 19 11:01:50 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Mon Apr 19 11:01:58 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: <1082386733.7365.104.camel@anthem.wooz.org> References: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> <1079387385.5149.292.camel@anthem.wooz.org> <2147483647.1079447849@beeding.central.susx.ac.uk> <1081472500.5071.39.camel@anthem.wooz.org> <2147483647.1082378212@beeding.central.susx.ac.uk> <1082386733.7365.104.camel@anthem.wooz.org> Message-ID: <851346923.1082390510@beeding.central.susx.ac.uk> --On Monday, April 19, 2004 10:58 am -0400 Barry Warsaw wrote: > On Mon, 2004-04-19 at 07:36, Ian A B Eiloart wrote: >> > Composability is probably an important concept for list styles. >> > >> > -Barry >> > >> >> What's that? > > The idea that you might have a "privacy" sub-style and a "bounces" > sub-style. Each would affect only a handful of list configuration > variables. You'd like to be able to combine them into super-styles that > would affect the union of those variables. But what do you mean by "composability"? -- Ian Eiloart Servers Team Sussex University ITS From barry at python.org Mon Apr 19 11:14:19 2004 From: barry at python.org (Barry Warsaw) Date: Mon Apr 19 11:14:28 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: <851346923.1082390510@beeding.central.susx.ac.uk> References: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> <1079387385.5149.292.camel@anthem.wooz.org> <2147483647.1079447849@beeding.central.susx.ac.uk> <1081472500.5071.39.camel@anthem.wooz.org> <2147483647.1082378212@beeding.central.susx.ac.uk> <1082386733.7365.104.camel@anthem.wooz.org> <851346923.1082390510@beeding.central.susx.ac.uk> Message-ID: <1082387659.7365.107.camel@anthem.wooz.org> On Mon, 2004-04-19 at 11:01, Ian A B Eiloart wrote: > > The idea that you might have a "privacy" sub-style and a "bounces" > > sub-style. Each would affect only a handful of list configuration > > variables. You'd like to be able to combine them into super-styles that > > would affect the union of those variables. > > But what do you mean by "composability"? The ability to compose a super-style, let's call it "Ian's-public-lists" from partial, or sub-styles, such as "open-subscription-members-only" privacy and "aggressive-bounce-disable" bounce style. -Barry From iane at sussex.ac.uk Mon Apr 19 11:17:48 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Mon Apr 19 11:17:56 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: <1082387659.7365.107.camel@anthem.wooz.org> References: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> <1079387385.5149.292.camel@anthem.wooz.org> <2147483647.1079447849@beeding.central.susx.ac.uk> <1081472500.5071.39.camel@anthem.wooz.org> <2147483647.1082378212@beeding.central.susx.ac.uk> <1082386733.7365.104.camel@anthem.wooz.org> <851346923.1082390510@beeding.central.susx.ac.uk> <1082387659.7365.107.camel@anthem.wooz.org> Message-ID: <1809306133.1082391468@beeding.central.susx.ac.uk> --On Monday, April 19, 2004 11:14 am -0400 Barry Warsaw wrote: > On Mon, 2004-04-19 at 11:01, Ian A B Eiloart wrote: > >> > The idea that you might have a "privacy" sub-style and a "bounces" >> > sub-style. Each would affect only a handful of list configuration >> > variables. You'd like to be able to combine them into super-styles >> > that would affect the union of those variables. >> >> But what do you mean by "composability"? > > The ability to compose a super-style, let's call it "Ian's-public-lists" > from partial, or sub-styles, such as "open-subscription-members-only" > privacy and "aggressive-bounce-disable" bounce style. > > -Barry I see. Yes, that would be good. -- Ian Eiloart Servers Team Sussex University ITS From barry at python.org Mon Apr 19 17:40:59 2004 From: barry at python.org (Barry Warsaw) Date: Mon Apr 19 17:41:34 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: <251498D6-922D-11D8-ABEE-000A957C9A50@ftel.co.uk> References: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> <1079387385.5149.292.camel@anthem.wooz.org> <2147483647.1079447849@beeding.central.susx.ac.uk> <1081472500.5071.39.camel@anthem.wooz.org> <2147483647.1082378212@beeding.central.susx.ac.uk> <1082386733.7365.104.camel@anthem.wooz.org> <851346923.1082390510@beeding.central.susx.ac.uk> <1082387659.7365.107.camel@anthem.wooz.org> <251498D6-922D-11D8-ABEE-000A957C9A50@ftel.co.uk> Message-ID: <1082410858.27714.14.camel@anthem.wooz.org> On Mon, 2004-04-19 at 14:12, Richard Barrett wrote: > Do you see this as being a form of inheritance hierarchy and is > composition going to be: > > either: a one-shot computation process in which given super-style is > derived from the then current state of its components at a particular > time and then left in that state unless and until a re-computation of > it is specifically called for. > > or: a computed composite rule for the super style saying how to derive > from the values defined in the components (presumably recursively) > which dynamically delivers the value of a particular attribute whenever > it is required, so that changes in components flow continuously through > the hierarchy. > > In either case, traceability of how a given attribute is derived for a > given "style" is an issue. Some form of "is affected by changes in X" > AND "changes in X have these consequences" analysis seems desirable if > surprise is not to be the order of the day when undertaking maintenance > of sub-styles. Particularly if the second way of composing I suggest > above is adopted, the "changes in X have these consequences" analysis > may be quite useful. IIUC, closer to the former than the latter. Thinking of my straw man implementation might help: we define a function that takes a single MailList object argument. The function is a "style". When the list object created, we pass it to the style function and it sets various attributes as it sees fit. Composition then, is simply an ordering of multiple functions to call on the MailList object after its initial creation. This is pretty simple for on-disk styles; the question is whether we can some how safely translate that to thru-the-web style creation. The alternative is that the site admin adds new styles by adding new functions, and exposing them to list creators (and possibly list admins) to pick and choose from. This model means that styles are one-shot affairs, applied to lists at creation time. Or possibly applied to lists some time later, via a manual step. A change to a style function therefore has no effect on existing lists and there's no reference from the list object to the style functions that were applied to it. That may not give us everything we'd want from a style system, but it probably passes the 80/20 rule and will be fairly simple to implement and document. -Barry From barry at python.org Mon Apr 19 17:56:18 2004 From: barry at python.org (Barry Warsaw) Date: Mon Apr 19 17:56:28 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: <407A67BD.4517.1A5388@localhost> References: <407A67BD.4517.1A5388@localhost> Message-ID: <1082411773.27714.29.camel@anthem.wooz.org> On Mon, 2004-04-12 at 09:56, Bryan Carbonnell wrote: > CSS editing is great for layout of content that is already in the > HTML > templates. > > I'm talking about adding actual content into the templates. > Specifically adding my site's navigation to the MM interface and > possibly customising it depending on where the user / admin is in the > interface. That should all be much easier with MM3 because we won't have the currently crufty situation where some of the web u/i lives in templates and other parts are generated from Python code. I feel fairly strongly that it should all live in templates. However, the question is really what power we'll give users to change the u/i through the web. Site admins with access to the file system will definitely be able to heavily modify the u/i to their heart's content. Web-only users will be limited to CSS changes. This won't make all the clients of Mailman hosting sites happy, but there's an opportunity for some value add proposition (in marketing speak :). -Barry From barry at python.org Mon Apr 19 21:04:43 2004 From: barry at python.org (Barry Warsaw) Date: Mon Apr 19 21:04:52 2004 Subject: [Mailman3-dev] common tests for all backends(can I move'm to mailman/tests)? In-Reply-To: <575AE2C2-8B0E-11D8-AD3E-000A95AB83D2@digitalcommute.com> References: <575AE2C2-8B0E-11D8-AD3E-000A95AB83D2@digitalcommute.com> Message-ID: <1082423082.11095.25.camel@anthem.wooz.org> On Sat, 2004-04-10 at 12:44, Michael Kato wrote: > I know you've probably already thought of this, but would it be ok to > move tests that are common across backends into mailman/tests? Yes, definitely. > I mean > can I yank tests out of some of the test cases in berkeleydb/tests and > place them into mailman/tests? Such as those that are common to all > backends like create_user etc. I'm also considering making it so that > test.py also takes a list of backends to test(any better ideas?) > Ideally I'd like the common tests to be run once for each backend. I think that's a good idea. I'm currently reworking the ZConfig-based configuration schema, and when I check that in, I /think/ the way it'll work is to have separate copies of mailman.conf that enable different backends. At the very least then, we can make test.py take an argument for the config file to use, and run the full suite of tests against the backend defined in there. We'll need to have config files that are unique to the test framework anyway, because we don't want tests corrupting the real databases (i.e. we'll need reproducible databases for reproducible tests). I'm not sure if we can convince test.py to run against more than one backend, but that /would/ be useful. It would have to be taught not to run against a non-existent backend though (as when you don't have berkeley installed or say in the future MySQL). > For instance, on the Mac OS X, I'm having trouble testing berkleydb > because python on the mac seems not to have bsddb support. (I may look > further into this...) > > But in any case, I think it would be nice to only test the backends > and other things that are of interest when running test.py > > ....maki.... > PS, what do you think of collecting all of the backend implementations > into on directory? Probably at some point, yes. Note that my long term goal is to get our source under Subversion so that kind of directory reorganization will be painless. ;) We'll either wait for SF to enable Subversion support or move someday. -Barry From barry at python.org Mon Apr 19 21:14:18 2004 From: barry at python.org (Barry Warsaw) Date: Mon Apr 19 21:14:27 2004 Subject: [Mailman3-dev] getting webserver to run with stubbackend; how about ITransactionManager.checkState()? In-Reply-To: <5F2FA0E4-8C37-11D8-B4DD-000A95AB83D2@digitalcommute.com> References: <5F2FA0E4-8C37-11D8-B4DD-000A95AB83D2@digitalcommute.com> Message-ID: <1082423657.11095.31.camel@anthem.wooz.org> On Mon, 2004-04-12 at 00:10, Michael Kato wrote: > Barry, > > I came across the following code, and thought perhaps the > ITransactionManager interface should support a method like checkState() > then the following code can be changed to use that instead. What do > you think? Excellent idea, I've added that (but note that my tree's a little broken atm so I hope I didn't introduce a bug ;). I'm going to try to finish up my config changes and then work on getting the tests working again. BTW, I want to stick pretty close to PEP 8 style guide, except where overridden by my own peculiarities. :) So methods should be called check_state() instead of checkState(). There are some exceptions, mostly based on said peculiarities, like isthing() usually being preferred over is_thing(). No worries though -- if you don't mind me pissing on the hydrant from time to time. :) Also, test_foo.py is probably preferrable to testFoo.py. -Barry http://www.python.org/peps/pep-0008.html http://barry.warsaw.us/software/STYLEGUIDE.txt From barry at python.org Mon Apr 19 21:24:30 2004 From: barry at python.org (Barry Warsaw) Date: Mon Apr 19 21:24:37 2004 Subject: [Mailman3-dev] PyProtocols or Zope interfaces? Message-ID: <1082424270.11095.44.camel@anthem.wooz.org> I'd like to re-open the discussion of which interfaces package we are going to use in MM3. Before I checked everything into the public cvs, I was using a snapshot of Zope3 interfaces from maybe 8 months ago. But then I switch to PyProtocols mostly because I found it pretty difficult to rip sub-packages out of Zope for distribution outside of Zope. Now however, Zope3 is gaining a packaging system that should make pulling useful stuff out of Zope much easier. It won't necessarily reduce inter-package dependencies, but at least it will handle them automatically for us, and should be able to provide us with distutils packages that we can simply include and install. There are two things I like about Zope3 interfaces now (these are new since the last time I stole from Zope3): calling an interface is syntactic sugar for a PEP 246-like adapt() call, and declarations on classes are more succinct. For the former, it means doing something like: from mailman.interfaces.transactions import ITransactionManager mgr = ITransactionManager(obj, None) if mgr is None: # adapt failed, or we could have omitted the second arg and # caught TypeError instead. That looks nice to me! For the latter, it means being able to say: class SomeClass: implements(IFoo) instead of the more wordy PyProtocols way (or the now-deprecated __implements__ = IFoo). The Z3 packaging system hasn't quite landed, but I know that it's a top priority and near completion. I'm inclined to switch back to Zope interfaces when this is ready. Also, I think the next version of PyProtocols will adopt callable interfaces, but probably won't adopt implements(). I'll note also that Twisted recently decided to switch to Zope interfaces, so it seems like there might be critical mass there. Comments? -Barry From barry at python.org Mon Apr 19 21:26:38 2004 From: barry at python.org (Barry Warsaw) Date: Mon Apr 19 21:26:45 2004 Subject: [Mailman3-dev] getting mm3 running on mac OSX 10.3 (or... In-Reply-To: References: Message-ID: <1082424397.11095.48.camel@anthem.wooz.org> On Sun, 2004-04-11 at 21:14, Michael Kato wrote: > I've changed one file(mailman/categories/tests/test_xmlstring) so > that it doesn't fail the tests. I've mostly been ignoring the tests > that fail in berkleydb/tests as it seems to be based on really old > code. As well as tests/test_lock.py as it seems to be testing lock.py > which is not referenced anywhere else. The tests are in a sorry state, and for that I apologize. I'm going to spend some time tonight getting the ZConfig stuff in order, and working on the tests. -Barry From iane at sussex.ac.uk Wed Apr 21 04:40:07 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Wed Apr 21 04:40:45 2004 Subject: [Mailman3-dev] Mailman Design In-Reply-To: <1082411773.27714.29.camel@anthem.wooz.org> References: <407A67BD.4517.1A5388@localhost> <1082411773.27714.29.camel@anthem.wooz.org> Message-ID: <2147483647.1082540407@[192.168.1.10]> --On Monday, April 19, 2004 5:56 pm -0400 Barry Warsaw wrote: > > That should all be much easier with MM3 because we won't have the > currently crufty situation where some of the web u/i lives in templates > and other parts are generated from Python code. I feel fairly strongly > that it should all live in templates. > > However, the question is really what power we'll give users to change > the u/i through the web. Site admins with access to the file system > will definitely be able to heavily modify the u/i to their heart's > content. That'll do me, provided that the templates aren't touched during an upgrade. -- Ian Eiloart Servers Team Sussex University ITS From iane at sussex.ac.uk Wed Apr 21 08:08:21 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Wed Apr 21 08:08:26 2004 Subject: [Mailman3-dev] Mailman Design Message-ID: <2147483647.1082552901@[192.168.1.10]> >>> However, the question is really what power we'll give users to change >>> the u/i through the web. Site admins with access to the file system >>> will definitely be able to heavily modify the u/i to their heart's >>> content. >> >> That'll do me, provided that the templates aren't touched during an >> upgrade. > > A good principle but one that begs the question of what policy to apply > where the whole point of an update is to introduce changed functionality > which is only available through the templates; err that's everything, is > it not. Ah, good point. Here's how I might approach the problem: Often what I want to do is change the descriptive text - for example I need to tell local staff which of their several email addresses they should subscribe with, so I add instructions above the appropriate slot. Perhaps the answer is to parameterise text descriptions, such that one file can contain default text, and a site specific file can override those defaults. That way, a 'template' wouldn't be plain html, but rather a python script which generated html. New functionality would imply new parameters with new defaults. The texts might be edited through the web, and might contain simple formatting (lists, emphasis, etc). You could even let admins include and exclude certain interface elements through the web (like password reminder choices, for example). Again, there could be default and override settings for inclusion of elements, but addition of new elements would mean changing a default settings file, whereas site specific settings would be unaffected: So, a 'template' for a sign-on page might look like this pseudo-code: > read /local/mailman/defaults/sign-on.settings > read ${local-settings-path}/styles/${list.style}/sign-on.settings > read ${local-settings-path)/lists/${list.name}/sign-on.settings > > if ($sign-on.digest_allowed) > echo $sign-on.digest_instructions > echo $sign-on.digest_interface > endif if fact, if you paramaterised the interface element, then admins could choose to change, say, a drop down list into a set of radio buttons. The default sign-on.settings might contain: $sign-on.digest_allowed = true $sign-on.digest_instructions = "Get $list-digest-frequency digests" $sign-on.digest_interface = "" Whereas the sitewide settings file may contain: $sign-on.digest_instructions = "Get $list-digest-frequency digests. click here for our digest policy." And the list specific settings file may say: $sign-on.digest_allowed = false Now, most people wouldn't want to touch the "interface" settings, but many may want to change the descriptions. The list specific "allowed" settings would largely be controlled by the list policy settings. However, it would be possible to permit styles by providing several site wide settings files. -- Ian Eiloart Servers Team Sussex University ITS From jmhayes at speakeasy.net Wed Apr 21 11:43:07 2004 From: jmhayes at speakeasy.net (Jordan Hayes) Date: Wed Apr 21 11:43:23 2004 Subject: [Mailman3-dev] Mailman Design References: <407A67BD.4517.1A5388@localhost><1082411773.27714.29.camel@anthem.wooz.org> <2147483647.1082540407@[192.168.1.10]> Message-ID: <02fd01c427b7$57d74280$1048a8c0@rupt> > provided that the templates aren't touched during an upgrade. It would be interesting to have a standard way of extending the templates without having to touch them; something like an "include" syntax that can tolerate missing files. The default would be to not have any of the pieces modified, but if you put some files in place, they'd get included. I'd like a way to add to the head (for javascript), before the headers (for ads), after the headers (for search engine support; I use SWISH-E), and after the message (for more ads and/or search engines, plus more javascript). This would also make it easier to make changes to all the languages at once. /jordan From mk2s at digitalcommute.com Thu Apr 22 00:44:10 2004 From: mk2s at digitalcommute.com (Michael Kato) Date: Thu Apr 22 00:44:08 2004 Subject: [Mailman3-dev] heads up; ZConfig dependency changed Message-ID: mm3 code base has been updated to use newer ZConfig. For those tracking mm3 CVS, you will need to update your ZConfig. I tried using http://zope.org/Members/fdrake/zconfig/ZConfig-2.1.tar.gz but was unsuccessful. Instead I ended up getting from CVS as described at the bottom of http://zope.org/Members/fdrake/zconfig/ and did a "python setup.py install --prefix=myprojdir/python" The forecast calls for config pain, for the next couple of days/weeks... ....maki.... From barry at python.org Thu Apr 22 09:58:42 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 22 09:58:54 2004 Subject: [Mailman3-dev] heads up; ZConfig dependency changed In-Reply-To: References: Message-ID: <1082642320.22227.73.camel@anthem.wooz.org> On Thu, 2004-04-22 at 00:44, Michael Kato wrote: > mm3 code base has been updated to use newer ZConfig. > > For those tracking mm3 CVS, you will need to update your ZConfig. I > tried using > http://zope.org/Members/fdrake/zconfig/ZConfig-2.1.tar.gz but was > unsuccessful. > > Instead I ended up getting from CVS as described at the bottom of > http://zope.org/Members/fdrake/zconfig/ and did a "python setup.py > install --prefix=myprojdir/python" > > The forecast calls for config pain, for the next couple of days/weeks... Hopefully not! :) Fred's created ZConfig 2.2 but hasn't uploaded it to the usual locations. I've updated getstuff.sh to point to a temporary copy. That should get you farther... -Barry From barry at python.org Thu Apr 22 11:50:34 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 22 11:50:52 2004 Subject: [Mailman3-dev] ZConfig 2.2 Message-ID: <1082649033.23443.1.camel@anthem.wooz.org> The package Fred released appears to have a bug in it -- or rather it is missing a bug fix I made prior to 2.2 tagging. Fred's looking into it but in the meantime, you can hand-apply the following patch. looks-like-maki-may-be-right-after-all-ly y'rs, -Barry --- python/lib/python2.3/site-packages/ZConfig/components/logger/handlers.py.~1~ 2004-04-13 15:34:19.000000000 -0400 +++ python/lib/python2.3/site-packages/ZConfig/components/logger/handlers.py 2004-04-22 11:41:40.000000000 -0400 @@ -32,6 +32,7 @@ 'relativeCreated': 1, 'thread': 1, 'message': 'amessage', + 'process': 1, } def log_format(value): From mk2s at digitalcommute.com Fri Apr 30 23:35:52 2004 From: mk2s at digitalcommute.com (Michael Kato) Date: Fri Apr 30 23:35:38 2004 Subject: [Mailman3-dev] added interface to subscription Message-ID: I've added the interface to subscriptions. I also have been reworking the tests to work better with test.py. Most of the tests that are valid are now working with both backends. To test the berkley backend, the bakendtest.conf needs to look like: path $vardir/listdb path $vardir/userdb storage lists bdblist storage users bdbuser # # # storage lists stublist # storage users stubuser Maybe soon I'll get around to fixing the test.py to take a conf file that then does the right thing. It seems to be running by chance because mailman/stubbackend/tests/test_config2.py is the first test file run, and happens to load a config that is then reused. I just discovered this and thought it was funny(that test.py runs by chance) ....maki....