From barry at python.org Mon Jul 3 17:43:20 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 3 Jul 2006 11:43:20 -0400 Subject: [Mailman-Developers] [Mailman-i18n] SoC: status update In-Reply-To: <44A406AA.9090406@mindlace.net> References: <4499A358.2040005@mindlace.net> <4499E69C.5020009@is.kochi-u.ac.jp> <44A406AA.9090406@mindlace.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 29, 2006, at 12:58 PM, emf wrote: > We will use UTF-8 exclusively on WUI, with the caveat that I will be > sniffing any charset information contained in emails and attempt > displaying (individual) emails with the charset referenced. I'm sure this was ages ago, but IIRC, UTF-8 was discussed at some point and the decision was made not to use it because it's support was pretty spotty in the browsers of the time. I'm sure this has improved vastly now and UTF-8 makes the most sense. > Pretty please, I need to set up a copy of someone's translation > toolchain; can someone using OS X or Linux as their work operating > system work with me to get an *exact* replica of their toolset? > > I want to make translating as painless as possible but from what I can > tell so far gettext is very low level and I suspect that people use > more > than just it to translate... am I right? Have you gotten any love on this issue Ethan? To be honest, I'm not a translator (heck, I barely speak English despite years of at least 2 other languages in high school and college :). When I was working out the basic i18n support I implemented a stupid rot13 translation using nothing more sophisticated than XEmacs and the gettext tools. Please, can any i18n'ers help Ethan out with a better tool set? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRKk7GHEjvBPtnXfVAQJ8SgP/dlOdTK59NTZrDrcWlSnD2iD29+rRazhx vO7xPUDpL68U2mhKhDVW7i3CN6afrvlR6yZ2+r6fxOJwQsEL1mjED4VCUQku6gQJ dCri7KNGGwFiLpWFSoq9OE35+p8IJg6mW1+rXokjBzuq76+uz9rI2leWhAcS1g/Y vMUeGZLhUCw= =LGTW -----END PGP SIGNATURE----- From barry at python.org Mon Jul 3 17:46:59 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 3 Jul 2006 11:46:59 -0400 Subject: [Mailman-Developers] bulk subscriber changes In-Reply-To: <44A40400.10702@mindlace.net> References: <449202D8.8060805@mindlace.net> <44987E3C.7000703@mindlace.net> <449983E0.90504@mindlace.net> <913E10752C2AD44178A62305@lewes.staff.uscs.susx.ac.uk> <44A3D810.5090103@mindlace.net> <44A40400.10702@mindlace.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 29, 2006, at 12:46 PM, emf wrote: > Yes, I very much want mass-manipulation :) as well. In addition to > bulk > unsub, I'm extending the membership management thingy to allow for > iterative searches (preserving existing results) so that you can > quickly > get to a set of email addresses you'd like to perform some > operation on. That sounds pretty cool. BTW, I should mention that I have made some progress on a SQLAlchemy based MemberAdaptor. I've had to make a couple of small modifications and additions to the API (mostly adding explicit transaction hooks and fixing some incorrect docstrings), and I still don't have the test suite quite working yet, but I'll post more about this later. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRKk783EjvBPtnXfVAQJ95gP/bvuwI6t1eUan5zxGE11kEMK30UUDKH1w +GGKW/O6moCwpU5mR5QbsrA14IwXRVVnryfmNlpFo2ivKjPT49lq0/0f7znCiREF +zDhriiWa9U/A73TtSIwwRY8bs5qUDB0DaD+3EoBH0drB76W203F+GOTetdRt3qo e6zNGBrkL7c= =XRZL -----END PGP SIGNATURE----- From t.d.lee at durham.ac.uk Tue Jul 4 19:18:04 2006 From: t.d.lee at durham.ac.uk (David Lee) Date: Tue, 4 Jul 2006 18:18:04 +0100 (BST) Subject: [Mailman-Developers] sender-based authentication Message-ID: A few weeks ago I opened a discussion "sender-based authorisation" about something similar to "Approved: password", but where the password would be associated with a person (sender) rather than a list. There seemed to be agreement in principle. (For the history, see that thread.) Being completely new to both Mailman and python programming (though with several years of majordomo and perl behind me!) I thought I'd check that I'm on the right lines. Attached is a shot at a "UserAuth.py" module(?) to maintain the passwords, with ideas borrowed from "Utils.py". Does it seem the right sort of thing? Does it conform to the spirit of Mailman? Or is it hopelessly wrong or idiosyncrantic? I've also written myself a little command-line maintenance program to add, modify, delete, list, etc. entries in the database. (I have no plans to put any user-oriented WWW front end to this at present; I want to get the module and the command-line interface functional. Initially, our local use would be for us, the service, to maintain the entries, not (yet) for users to be able to maintain it.) Thoughts? -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : -------------- next part -------------- #! /usr/bin/python # # Copyright (C) 2006 David Lee, Durham University, UK # # <> # """User (site-wide) table maintenance""" import os import sha import dbm #filename = os.path.join(DATA_DIR, 'userpw') filename = 'userpw' def add(user=None, password=None): oldmask = os.umask(026) try: file = dbm.open(filename, 'c') if file.has_key(user): raise KeyError file[user] = sha.new(password).hexdigest() file.close() finally: os.umask(oldmask) def check(user=None, password=None): file = dbm.open(filename, 'r') if not file.has_key(user): raise KeyError pwsha = file[user] file.close() return pwsha == sha.new(password).hexdigest() def delete(user=None): oldmask = os.umask(026) try: file = dbm.open(filename, 'c') if not file.has_key(user): raise KeyError del file[user] file.close() finally: os.umask(oldmask) def list(): file = dbm.open(filename, 'r') lret = {} for key in file.keys(): lret[key] = file[key] file.close() return lret def modify(user=None, password=None): oldmask = os.umask(026) try: file = dbm.open(filename, 'c') if not file.has_key(user): raise KeyError file[user] = sha.new(password).hexdigest() file.close() finally: os.umask(oldmask) From i at mindlace.net Tue Jul 4 19:30:45 2006 From: i at mindlace.net (emf) Date: Tue, 04 Jul 2006 13:30:45 -0400 Subject: [Mailman-Developers] Please Tell Me How You Translate In-Reply-To: References: <4499A358.2040005@mindlace.net> <4499E69C.5020009@is.kochi-u.ac.jp> <44A406AA.9090406@mindlace.net> Message-ID: <44AAA5C5.20701@mindlace.net> Barry Warsaw wrote: > I'm sure this was ages ago, but IIRC, UTF-8 was discussed at some point > and the decision was made not to use it because it's support was pretty > spotty in the browsers of the time. I'm sure this has improved vastly > now and UTF-8 makes the most sense. Yeah, that sounds like an early-90's conversation; UTF-8 is the one charset no browser messes up these days, as far as I know. >> Pretty please, I need to set up a copy of someone's translation >> toolchain; can someone using OS X or Linux as their work operating >> system work with me to get an *exact* replica of their toolset? > Have you gotten any love on this issue Ethan? No love as of this writing. I'm continuing to kick the i18n ball down the field until I can do a translation myself (into gods-knows-what - I'll probably have to rely on my lovely and talented wife to give Russian/Italian a stab.) > When I was working out > the basic i18n support I implemented a stupid rot13 translation using > nothing more sophisticated than XEmacs and the gettext tools. Yeah, I can do that if need be. I just assumed there was Something More out there; if not it might be worth the effort to put together a minimalist translation interface. ~ethan From i at mindlace.net Tue Jul 4 19:45:15 2006 From: i at mindlace.net (emf) Date: Tue, 04 Jul 2006 13:45:15 -0400 Subject: [Mailman-Developers] Turning off dynamic JavaScript Message-ID: <44AAA92B.1050905@mindlace.net> Gentlebeings, I have read a depressing and recent article suggesting that DOM manipulations are invisible to most screen readers [1]. There are some workarounds suggested in [2], but for the most part it looks like dangerous territory. What's worse, there seems to be no way to detect screen readers reliably. I am determined to provide some JavaScript in the 'standard' interface, as it will make for enhanced ease-of-use for those sighted people using a modern browser. (I think it would be good for screen readers, too, if there was just some way for me to control/hint the "focus" of the screen reader, but at the moment there doesn't seem to be. Screen readers don't even seem to support an aural/speech stylesheet, much less provide some JavaScript object that lets me know I'm in one.) I found a page (that is eluding me at the moment) detailing a method for showing content to screen readers yet hiding it from 'regular' clients. I was thinking of adding a "Screen Reader Support On" link to the top of all pages that would only show to screen readers; does this seem like a good approach? Note that this would be in *addition* to the ability to get a JS-free version of the interface by using a different URL prefix for any user agent that doesn't want the JS action. ~ethan From brad at stop.mail-abuse.org Tue Jul 4 19:59:59 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue, 4 Jul 2006 13:59:59 -0400 (EDT) Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: <44AAA92B.1050905@mindlace.net> References: <44AAA92B.1050905@mindlace.net> Message-ID: <34367.72.177.126.107.1152035999.squirrel@mail.his.com> Ethan wrote: > Note that this would be in *addition* to the ability to get a JS-free > version of the interface by using a different URL prefix for any user > agent that doesn't want the JS action. Speaking only for myself, this is not the kind of approach I'd like to see used. I'd prefer to see the web application auto-detect that JavaScript is not available, and therefore to automatically present the appropriate non-JavaScript interface. Likewise, it should auto-detect that there is a screen reader being used, and present the appropriate screen reader compatible interface. Of course, the manual options should always be there, but if we're forcing the user to manually select a different page in order to get away from the JavaScript stuff, then I think we're doing something wrong. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From brad at stop.mail-abuse.org Tue Jul 4 20:02:40 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue, 4 Jul 2006 14:02:40 -0400 (EDT) Subject: [Mailman-Developers] Please Tell Me How You Translate In-Reply-To: <44AAA5C5.20701@mindlace.net> References: <4499A358.2040005@mindlace.net> <4499E69C.5020009@is.kochi-u.ac.jp> <44A406AA.9090406@mindlace.net> <44AAA5C5.20701@mindlace.net> Message-ID: <34375.72.177.126.107.1152036160.squirrel@mail.his.com> Ethan replied to Barry: >>> Pretty please, I need to set up a copy of someone's translation >>> toolchain; can someone using OS X or Linux as their work operating >>> system work with me to get an *exact* replica of their toolset? >> >> Have you gotten any love on this issue Ethan? > > No love as of this writing. I'm continuing to kick the i18n ball down > the field until I can do a translation myself (into gods-knows-what - > I'll probably have to rely on my lovely and talented wife to give > Russian/Italian a stab.) I've got MacOS X 10.4, but I don't do any sort of translation, and I don't have the slightest clue as to how you'd go about trying to do that. I don't speak any foreign language well enough to even think about making any attempt to do so. That said, I'd be glad to provide whatever help I can. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From i at mindlace.net Tue Jul 4 20:06:27 2006 From: i at mindlace.net (emf) Date: Tue, 04 Jul 2006 14:06:27 -0400 Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: <34367.72.177.126.107.1152035999.squirrel@mail.his.com> References: <44AAA92B.1050905@mindlace.net> <34367.72.177.126.107.1152035999.squirrel@mail.his.com> Message-ID: <44AAAE23.9000702@mindlace.net> Brad Knowles wrote: > Speaking only for myself, this is not the kind of approach I'd like to see > used. I'd prefer to see the web application auto-detect that JavaScript > is not available, and therefore to automatically present the appropriate > non-JavaScript interface. I will do this for browsers not employing JavaScript. Screen readers employ JavaScript and provide no indication what they do/do not provide feedback to the user for. > Likewise, it should auto-detect that there is a > screen reader being used, and present the appropriate screen reader > compatible interface. This is an admirable goal. One "screen reader" in semi-common use is IE 6 via Jaws; another one is Safari with OS X reading turned on. They present to me no handle, user-agent or otherwise, indicating they're being spoken rather than seen. > Of course, the manual options should always be there, but if we're forcing > the user to manually select a different page in order to get away from the > JavaScript stuff, then I think we're doing something wrong. I agree that it is an Ugly Hack; In this case I think the screen readers are misbehaved, but there's not a lot I can do about that. ~ethan fremen From i at mindlace.net Tue Jul 4 20:11:23 2006 From: i at mindlace.net (emf) Date: Tue, 04 Jul 2006 14:11:23 -0400 Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: <44AAAE23.9000702@mindlace.net> References: <44AAA92B.1050905@mindlace.net> <34367.72.177.126.107.1152035999.squirrel@mail.his.com> <44AAAE23.9000702@mindlace.net> Message-ID: <44AAAF4B.8030506@mindlace.net> emf wrote: >> Likewise, it should auto-detect that there is a >> screen reader being used, and present the appropriate screen reader >> compatible interface. > > This is an admirable goal. One "screen reader" in semi-common use is IE > 6 via Jaws; another one is Safari with OS X reading turned on. er, I mean via window eyes; other web browsers can be used this way as well. ~ethan fremen From i at mindlace.net Tue Jul 4 21:44:03 2006 From: i at mindlace.net (emf) Date: Tue, 04 Jul 2006 15:44:03 -0400 Subject: [Mailman-Developers] Parsing and Rendering rfc8222 Message-ID: <44AAC503.9020901@mindlace.net> Dearest mail manipulating macaques and perambulating python prestidigitators, I have been blessed by the grace of Google and so am working full-time on improving Mailman's web UI: http://wiki.list.org/display/DEV/Summer+of+Code In order to provide interfaces to archives, I believe I must perform some intermediary manipulation; my goal is to get the information contained within the .mbox files mailman generates into ElementTrees and other objects so as to represent them via HTML/RSS/Atom/etc. This is slightly out of scope for the web-UI project, as it is mostly about data model rather than actual user interface. In the interest of not reinventing the wheel, I'm looking for existing python (or other!) code that does the things I need. I'm also putting out a call for anybody who likes this sort of thing to help me out (see below). Here's where I'm at, grouped functionally: * Need to convert rfc8222 to xml/html I haven't found anything substantial via searching. My next step is to go spelunking in MailManager code and other python-webmail packages. If anyone knows good trees in this forest, please clue me in. * Want to provide feeds (rss/atom/YourMommasSyntaxFormat) Right this second I'm planning on using pyfeed [1]; is there anything else I should consider? [1] http://home.blarg.net/~steveha/pyfeed.html * mbox thread indexing on messages I plan on using [2] to generate mbox thread indexes for rapid navigation of lists. Any suggestions for more robust variants would be welcome; feedback on how to handle threading for message-id-less messages would also be welcome. [2] http://benno.id.au/code/archiver/jwzthreading.py * full-text indexing pylucene seems to be the obvious choice; anything else I should consider? Anyone know of good pylucene/web UI glue code out there? (eg. something that leverages knowledge of the index to provide suggested keywords/tag cloud and/or tab-completion) As to help, I am first and foremost interested in someone willing to write renderers as above and check it in to my branch. I am also, however, interested in any advice, suggestions, dear-gods-whatever-you-do-don't-do-x comments, critiques of what is already checked in (zero python code, much html so far), pats on the back or other goodies (snailmail address available on request ;) I do ask that you send anything not related to my above question directly to me, bypassing the list; I'd also humbly ask you to read the wiki page before telling me I should do XYZ; I may already be doing it. I'm not actually subbed to python-list because I lack the stamina, so please cc: me on any follow ups. Thank you for your generous assistance, ~ethan fremen From barry at python.org Tue Jul 4 22:30:51 2006 From: barry at python.org (Barry Warsaw) Date: Tue, 4 Jul 2006 16:30:51 -0400 Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: <44AAAE23.9000702@mindlace.net> References: <44AAA92B.1050905@mindlace.net> <34367.72.177.126.107.1152035999.squirrel@mail.his.com> <44AAAE23.9000702@mindlace.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 4, 2006, at 2:06 PM, emf wrote: > Brad Knowles wrote: > >> Speaking only for myself, this is not the kind of approach I'd >> like to see >> used. I'd prefer to see the web application auto-detect that >> JavaScript >> is not available, and therefore to automatically present the >> appropriate >> non-JavaScript interface. > > I will do this for browsers not employing JavaScript. Screen readers > employ JavaScript and provide no indication what they do/do not > provide > feedback to the user for. Will this also work for browsers with JS enabled per-page, a la the Firefox NoScript extension? I use that to control which sites I allow JS on, and while I generally would enable it (and cookies) for most Mailman sites, I could definitely see others disabling it. As for the screen reader issue, well, you gotta work with what they give you I guess. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRKrP+3EjvBPtnXfVAQLjWAP/Zr9ttcyuwFjau9cP9EnW1yaWmezhijM5 7NgoSoFhmbdYvH1a63XLjhhIWrkqxatK9Hnw+XmnHs/u+dNqQW31MLWQh9FLCTNh SBMqHqCUR1PAon65bJ9ZIzZIEEqqCWrAoysBjd2+GFltQwHhOsUs/CFblcTFXWQM Whc1iWTaZBQ= =kUtF -----END PGP SIGNATURE----- From brad at stop.mail-abuse.org Tue Jul 4 23:25:45 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue, 4 Jul 2006 17:25:45 -0400 (EDT) Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: References: <44AAA92B.1050905@mindlace.net> <34367.72.177.126.107.1152035999.squirrel@mail.his.com> <44AAAE23.9000702@mindlace.net> Message-ID: <34727.72.177.126.107.1152048345.squirrel@mail.his.com> Barry Warsaw wrote: >> I will do this for browsers not employing JavaScript. Screen readers >> employ JavaScript and provide no indication what they do/do not >> provide >> feedback to the user for. > > Will this also work for browsers with JS enabled per-page, a la the > Firefox NoScript extension? I use that to control which sites I > allow JS on, and while I generally would enable it (and cookies) for > most Mailman sites, I could definitely see others disabling it. I also do this with Firefox, and an equivalent for Safari (using PithHelmet). I would generally turn on JavaScript for those sites I consider to be "safe", such as the mail.python.org or any other Mailman site I help administer, but I can certainly see that others might not feel the same way. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From brad at stop.mail-abuse.org Tue Jul 4 23:33:24 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue, 4 Jul 2006 17:33:24 -0400 (EDT) Subject: [Mailman-Developers] Parsing and Rendering rfc8222 In-Reply-To: <44AAC503.9020901@mindlace.net> References: <44AAC503.9020901@mindlace.net> Message-ID: <34837.72.177.126.107.1152048804.squirrel@mail.his.com> Ethan said: > In the interest of not reinventing the wheel, I'm looking for existing > python (or other!) code that does the things I need. I'm also putting > out a call for anybody who likes this sort of thing to help me out (see > below). Don't ignore non-Python solutions. In particular, you should take a close look at what Richard Barrett is doing with his ht:dig patch for the current versions of Mailman. At the very least, this is what most Mailman administrators are likely to expect, and you should have some idea of what they're going to be looking for before you throw something totally new and unfamiliar at them. > * mbox thread indexing on messages > > I plan on using [2] to generate mbox thread indexes for rapid navigation > of lists. Any suggestions for more robust variants would be welcome; > feedback on how to handle threading for message-id-less messages would > also be welcome. All messages should have message-ids -- this is one of the most basic requirements of the Internet e-mail related RFCs. If nothing else, the local MTA on the Mailman server should have provided a message-id. That said, if you still don't find one, then I think you should select a suitable method for generating them (take a look at the code in postfix or sendmail), and then apply that. > * full-text indexing > > pylucene seems to be the obvious choice; anything else I should > consider? Anyone know of good pylucene/web UI glue code out there? Again, I urge you to look at the existing ht:dig stuff. For that matter, you should probably also look at mail-archive.com and other similar sites to see what they've got and make sure that you either fully implement all the same features (in a way that makes sense), or that you know which features you're not going to implement and why. It all comes down to knowing what the expectations are for people who are going to be administering and using Mailman, and then being able to manage those expectations with regards to what you're doing. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From msapiro at value.net Wed Jul 5 06:30:29 2006 From: msapiro at value.net (Mark Sapiro) Date: Tue, 4 Jul 2006 21:30:29 -0700 Subject: [Mailman-Developers] Parsing and Rendering rfc8222 In-Reply-To: <34837.72.177.126.107.1152048804.squirrel@mail.his.com> Message-ID: Brad Knowles wrote: >Ethan said: > >> I plan on using [2] to generate mbox thread indexes for rapid navigation >> of lists. Any suggestions for more robust variants would be welcome; >> feedback on how to handle threading for message-id-less messages would >> also be welcome. > >All messages should have message-ids -- this is one of the most basic >requirements of the Internet e-mail related RFCs. If nothing else, the >local MTA on the Mailman server should have provided a message-id. I interpreted Ethan's concern to be messages that lack References: and In-Reply-To: rather than a Message-ID: per se. Also, generating a Message-ID: at archiving time does no good (at least in the absence of an archive interface to allow replying to an archive post) because it's too late to get that id into References: and/or In-Reply-To: of email replies. Also there is a related issue if A posts, B replies, A replies off list to B, and B replies on list. If threading relies solely on References: or In-Reply-To:, and either A's or B's MUA generates only In-Reply-To, this thread is broken at the 'missing' post. I don't have any really good suggestions for alternative threading algorithms however. I think there was something on this not too long ago on mailman-users or maybe mailman-developers - I looked and found what I think I remember. The relevant post is at and points to a description of an algorithm at . -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From iane at sussex.ac.uk Wed Jul 5 12:19:32 2006 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 05 Jul 2006 11:19:32 +0100 Subject: [Mailman-Developers] Parsing and Rendering rfc8222 In-Reply-To: <44AAC503.9020901@mindlace.net> References: <44AAC503.9020901@mindlace.net> Message-ID: <5F9167F185C38011D2066E27@lewes.staff.uscs.susx.ac.uk> > * Need to convert rfc8222 to xml/html > > I haven't found anything substantial via searching. My next step is to > go spelunking in MailManager code and other python-webmail packages. If > anyone knows good trees in this forest, please clue me in. > Do you mean 2822? or 822? 8222 doesn't exist. Any particular part of it? Addresses? Headers? Whole messages? -- Ian Eiloart IT Services, University of Sussex From lcarlson at d.umn.edu Wed Jul 5 14:44:18 2006 From: lcarlson at d.umn.edu (Laura Carlson) Date: Wed, 05 Jul 2006 07:44:18 -0500 Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: References: Message-ID: <54501BBF7228562B05E51B68@lcarslon.d.umn.edu> --On Tuesday, July 4, 2006 9:44 PM +0200 emf wrote: > I am determined to provide some JavaScript in the 'standard' > interface, as it will make for enhanced ease-of-use for those sighted > people using a modern browser. Hi Ethan, It says in 6.3 of WCAG 1.0 to "Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page." [1] Developers can use javascript as long as it degrades gracefully/is for progressive enhancement or if they provide an accessible alternative. If developers want use JavaScript, then they also need to be very sure that what they write is accessible to devices like screen readers, magnification software, keyboard only control, voice-only control, feet-based mice. If developers are willing to support these situations in a responsible manner (thorough testing with real assistive technology users is key), then they can write JavaScript. Current browser-based screenreaders do support javascript, but its practical scripting capabilities are nothing like the same as the browser used on its own (in terms of the interface elements it can use, and whether it can see/read updates to the DOM), yet you can't reliably detect the difference programmatically. Heavyweight DOM scripting, often results in inaccessible content, because events used are mouse-specific and changes to the page are not always announced to users. The result might be perfectly accessible content on a page, but a screen reader user may not know that the new content exists or even if the user knows that it exists he probably doesn't know where to find it on the page. Another difficulty often occurs when developers make things that look like controls on a page, but the information needed by assistive technologies like explicit labels are not present, and the accessibility and user experience for disabled users suffers. It is fine to use javascript, unobtrusively, but, one should be aware of accessibility issues, and, if you don't NEED javascript for something that you can do it server side, often the server-side solution would make more sense. It is far easier to deal with accessible JavaScript by ensuring that the core service being provided is not reliant on scripting. That way, if for some reason the JavaScript is inaccessible, it can be disabled in a browser, and thus the core functionality remains accessible. This is a safety net for developers, as well as visitors. You can guarantee things server side. You can't client side. Maybe 100% of your users use javascript. Maybe 80% use it. Maybe some have figured out how to circumvent the javascript and submit invalid data to the server. Maybe they are not using the latest alternative devices that support Javascript. Maybe they are blind and hate the way many sites use javascript to manipulate the browser client-side making it hard for them to navigate from page to page and so have shut it off. Even people with perfectly modern computers who have 20/20 eyesight, full cognitive and motor skills will turn off Java Support in their browser. The point is that all things being equal, it makes more sense to get the server-side logic working first, because it's more reliable. After that, use Javascript to enhance the usability features for the majority of users, without negatively affecting the accessibility. You should always fall back on a plain HTML or server-side solution for the benefit JavaScript provides. In my opinion accessibility and Javascript boil down to one question: if you take away/disable javascript, will this prevent the user from accessing or retrieving the information? Best regards, Laura [1] http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-scripts Related References: http://www.d.umn.edu/goto/javascript#access http://www.d.umn.edu/goto/javascript#ajaxaccess ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ From ehrbar at lists.econ.utah.edu Wed Jul 5 16:01:05 2006 From: ehrbar at lists.econ.utah.edu (Hans G. Ehrbar) Date: Wed, 05 Jul 2006 08:01:05 -0600 Subject: [Mailman-Developers] Parsing and Rendering rfc8222 In-Reply-To: <5F9167F185C38011D2066E27@lewes.staff.uscs.susx.ac.uk> (message from Ian Eiloart on Wed, 05 Jul 2006 11:19:32 +0100) References: <44AAC503.9020901@mindlace.net> <5F9167F185C38011D2066E27@lewes.staff.uscs.susx.ac.uk> Message-ID: If mailman would be able to write an xml representation of each message to a separate file, that would be wonderful. Then one would be able to use xlst stylesheets to make custom archives. I hacked something like this together for an on-line class. The workflow was: (1) mailman writes each message to disk as xml file, while at the same time also distributing the messages to the students. (2) I crawled these xml files with emacs (could also have been python but I was more comfortable with emacs) to concentrate as much info into each individual file as possible: each file had elements indicating which was the previous and the next message by the same student, and the previous and next message answering the same study question. If a student was referring to other messages in his message, this was also coded in xml in such a way that hyperlinks could be built from that code. (3) I also manually encoded the grade into this xml file, and included commentaries about the homework which would be visible in the archive, and commentaries which would only be sent privately to the student. If the answer was written so poorly that I had to edit the whole thing, then the original and the edited version was visible side by side in the archive. (4) different xlst stylesheets produced an archive of all messages with my comments accessible to all students, grade notification emails, and survey reports for every student about all of his or her grades. This is only one example. A translation of a mailing list discussion into a series of xml files can have many applications. Apparently there does not seem to be a generally accepted xml schema for email messages. I do not understand why. I would have thought this would be one of the first things to evolve after the xml specification was finalized. Am I missing something? Is it the difficulty to code all the non-standards compliant emails? Wouldn't it possible without too much trouble to turn the internal python representation of emails into xml? Hans G. Ehrbar -- Hans G. Ehrbar http://www.econ.utah.edu/~ehrbar ehrbar at economics.utah.edu Economics Department, University of Utah (801) 581 7797 (my office) 1645 Campus Center Dr., Rm 308 (801) 581 7481 (econ office) Salt Lake City UT 84112-9300 (801) 585 5649 (FAX) From t.d.lee at durham.ac.uk Wed Jul 5 16:26:25 2006 From: t.d.lee at durham.ac.uk (David Lee) Date: Wed, 5 Jul 2006 15:26:25 +0100 (BST) Subject: [Mailman-Developers] LoopError vs. Approve.py Message-ID: (Mailman 2.1.8) Probably trivial; probably my misunderstanding. But... ... at the end of "Approve.py" is some code to detect multiple passes through a list ("x-beenthere" etc.). But "Approve.py" is about handling passwords, whereas loop-detection has no relation to such authentication issues. Shouldn't this loop detection functionality be in some other place, not "Approve.py"? For instance, perhaps in its own, almost trivial, handler? (I noticed it because I'm writing an experimental sender-authentication scheme as a custom handler modelled on "Approve.py".) BTW: Overall, as I dig into the Mailman code, I'm increasingly impressed with its usually clean modularisation and its flexibility. So this loop-detection (mis-)placement seems out of character. Many thanks for a good product. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : From jdennis at redhat.com Wed Jul 5 16:55:45 2006 From: jdennis at redhat.com (John Dennis) Date: Wed, 05 Jul 2006 10:55:45 -0400 Subject: [Mailman-Developers] Parsing and Rendering rfc8222 In-Reply-To: <44AAC503.9020901@mindlace.net> References: <44AAC503.9020901@mindlace.net> Message-ID: <1152111345.32574.18.camel@finch.boston.redhat.com> On Tue, 2006-07-04 at 15:44 -0400, emf wrote: > In order to provide interfaces to archives, I believe I must perform > some intermediary manipulation; my goal is to get the information > contained within the .mbox files mailman generates into ElementTrees and > other objects so as to represent them via HTML/RSS/Atom/etc. It's not at all clear to me that mailman should be responsible for archiving. Archiving and MLM (Mailing List Manager) functionality can be orthogonal to each other. Archiving has a complex feature set if it's done right, and it's complex to implement. There are many items on Mailman's UI task list which need attention and can be done independently of also trying to tackle the 800 pound gorilla known as archiving. If we do anything in the near term with archiving I suggest it be only to clean up and further define an interface between Mailman as a MLM and an independent mail archiver which would allow installations to install the mail archiver of their choice along side of Mailman. I seem to recall this is also Barry's preference who noted the existing pipermail was only a stop-gap solution so there would be some default archiver, but it was never the intention Mailman would have any extensive archiving implementation. For what its worth I went looking for best of breed in open source archivers about 6 months ago and what I came up with was a project called "Lurker" (http://lurker.sourceforge.net) IMHO let the archiving experts deal with archiving, let the MLM experts (e.g. Mailman) deal with managing mailing lists. I recognize that Mailman would benefit from tighter integration with the archiver such that it is possible to automatically include links in mail which is being redistributed by the MLM, but rather than bringing any of this functionality into Mailman lets define the interfaces which are needed such that Mailman can operate cooperatively with any archiver which supports a well defined API. -- John Dennis Red Hat Inc. From i at mindlace.net Wed Jul 5 20:04:55 2006 From: i at mindlace.net (emf) Date: Wed, 05 Jul 2006 14:04:55 -0400 Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: <44AAA92B.1050905@mindlace.net> References: <44AAA92B.1050905@mindlace.net> Message-ID: <44ABFF47.3060001@mindlace.net> emf wrote: > Gentlebeings, > > I have read a depressing and recent article suggesting that DOM > manipulations are invisible to most screen readers [1]. There are some > workarounds suggested in [2], but for the most part it looks like > dangerous territory. Silly me, I didn't include the links. [1] http://www.sitepoint.com/article/ajax-screenreaders-work [2] http://juicystudio.com/article/making-ajax-work-with-screen-readers.php ~ethan From i at mindlace.net Wed Jul 5 20:26:39 2006 From: i at mindlace.net (emf) Date: Wed, 05 Jul 2006 14:26:39 -0400 Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: <54501BBF7228562B05E51B68@lcarslon.d.umn.edu> References: <54501BBF7228562B05E51B68@lcarslon.d.umn.edu> Message-ID: <44AC045F.9030908@mindlace.net> Laura Carlson wrote: > Heavyweight DOM scripting, often results in inaccessible content, The main point I'm driving at is *any* dom manipulation - heavy, light, fat-free, or decaf - appears to be invisible to the screen reading user unless I do it "downstream" of the focused text. I'm talking super-simple stuff like element.style.display='none' or "highlighting" text on another part of the page. I don't think it's reasonable to argue that I need to reduce usability for sighted users in order to cater to the (sadly) poor implementation of current screen readers. > It is fine to use javascript, unobtrusively, but, one should be aware > of accessibility issues, and, if you don't NEED javascript for > something that you can do it server side, often the server-side > solution would make more sense. For the most part I'm talking about things that aren't doable on the server. Visual feedback is extremely important for assisting sighted readers. Highlighting changes transiently, simplifying pages by hiding elements until they're needed, providing immediate error/warning/information messages, and allowing partial form submission are all things that make for a user experience that is much easier for the sighted user to grasp. I have read from several places that the ability to "play" - i.e. make changes iteratively and receive immediate feedback - encourages interaction and experimentation. Is this "needed"? No. Is it part of a good user interface for the bulk of users? Yes. Many of these tactics - including highlighting (i.e. 're-read this section'), hiding elements (don't read this until such-and-such happens), immediate messages (read this now) and partial form submission would all be helpful to people using screen readers. If I had *any bloody way* to tell a screen reader what to read next, none of what I'm doing would need to be disabled for the screen reader with JavaScript. > It is far easier to deal with accessible JavaScript by ensuring that > the core service being provided is not reliant on scripting. That way, > if for some reason the JavaScript is inaccessible, it can be disabled > in a browser, and thus the core functionality remains accessible. Are you suggesting I provide *no* link for the screen-reader-with-javascript client and let them at some point figure out that they're not seeing what's going on and thus turn off javascript? That seems like a worse solution. > In my opinion accessibility and Javascript boil down to one question: > if you take away/disable javascript, will this prevent the user from > accessing or retrieving the information? The problem I face is not when JavaScript is not active, the problem is when JavaScript *is* active *and* behaves correctly - i.e. performs the dom modification I've told it to - but the browser/screen reader doesn't bother to tell the user. ~ethan fremen From jwblist3 at olympus.net Wed Jul 5 20:54:13 2006 From: jwblist3 at olympus.net (John W. Baxter) Date: Wed, 05 Jul 2006 11:54:13 -0700 Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: <44AC045F.9030908@mindlace.net> Message-ID: On 7/5/06 11:26 AM, "emf" wrote: > The problem I face is not when JavaScript is not active, the problem is > when JavaScript *is* active *and* behaves correctly - i.e. performs the > dom modification I've told it to - but the browser/screen reader doesn't > bother to tell the user. > > ~ethan fremen Does the industry (I almost wrote "do we") know how big a problem this is in practice? That is, what fraction of users of screen readers and other assistive stuff routinely run with JavaScript active? Since the assertion here is "screenreaders have trouble with JavaScript" I would expect most screenreader users to have JavaScript turned off. --John From barry at python.org Wed Jul 5 21:12:52 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 5 Jul 2006 15:12:52 -0400 Subject: [Mailman-Developers] LoopError vs. Approve.py In-Reply-To: References: Message-ID: <985470DF-4754-4C82-A831-BBF492E1E898@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 5, 2006, at 10:26 AM, David Lee wrote: > (Mailman 2.1.8) > > Probably trivial; probably my misunderstanding. But... > > ... at the end of "Approve.py" is some code to detect multiple passes > through a list ("x-beenthere" etc.). > > But "Approve.py" is about handling passwords, whereas loop- > detection has > no relation to such authentication issues. Shouldn't this loop > detection > functionality be in some other place, not "Approve.py"? For instance, > perhaps in its own, almost trivial, handler? Ideally, yes, that's probably how it should (eventually?) be implemented. It's the way it is mostly due to historical accident. > (I noticed it because I'm writing an experimental sender- > authentication > scheme as a custom handler modelled on "Approve.py".) > > BTW: Overall, as I dig into the Mailman code, I'm increasingly > impressed > with its usually clean modularisation and its flexibility. So this > loop-detection (mis-)placement seems out of character. > > Many thanks for a good product. Thanks! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRKwPOXEjvBPtnXfVAQIdfQQAqgA88zshuPd1QGTdmqpL68TLx3aEoaWD jKZTEqhK5AdX0NhWrBysrsXfCITlijnhUF7JFjNL3ewUm8jB6WyimQ/+dhW+/FId tetu3f7C6jzA6ofb9DAaxnHfYDbf9xG9+jUXwBQTr/B8bhGG4bPAYMF3xq2neGRR NdL9Cvc+ekE= =EPSm -----END PGP SIGNATURE----- From lcarlson at d.umn.edu Wed Jul 5 22:19:31 2006 From: lcarlson at d.umn.edu (Laura Carlson) Date: Wed, 05 Jul 2006 15:19:31 -0500 Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: References: Message-ID: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> --On Wednesday, July 5, 2006 8:54 PM +0200 emf wrote: > Are you suggesting I provide *no* link for the > screen-reader-with-javascript client and let them at some point > figure out that they're not seeing what's going on and thus turn off > javascript? > > That seems like a worse solution. I'm suggesting that javascript is fine to use for progressive enhancement but not for core functionality. Javascript should be used to enhance the usability, _if_ it doesn't negatively affect accessibility. A Javascript dependent app is just not accessible. But like it says in 6.3 of WCAG 1.0, if it is not possible to make pages accessible when scripts, applets, or other programmatic objects are turned off or not supported, the fallback is to provide equivalent information on an alternative accessible page. SitePoint's JavaScript Anthology chapter on JavaScript and accessibility that features a lot of test results with different screen readers, but I don't see that as much more use than a DHTML script that was tested in 1999 on Netscape and IE - by making your DHTML accessibility dependent on the user agent - regardless of screen reader or browser - you make it easily outdated. The problem is not only users of assistive technology, it is about availability as well. What if I work in a high security environment where my employer turns off JavaScript or filters it out via a proxy by default? What if I am somewhere without internet access on the ground and want to use my mobile or satellite phone to reach an app? In both Section 508 and WCAG 1.0 a separate text only version is not considered an accessible solution. Basically the requirements state that the author has determined that the primary site CANNOT be made accessible, and the text only site provides some kind of second class access to the content. Creating a text-only version of a web site should be done when there is no other way to make the content accessible, or when it offers significant advantages over the main version. And then the text-only version needs to provide the functionality equivalent to that of the main version. Some thing to consider with separate versions: Text-only versions are rarely totally equivalent in content to the "real" version. They often do not fully convey content and its context. They effectively segregate the audience they are targeted at. When there is a text-only version available, developers sometimes do not make the "real" version accessible. >From a maintenance view, creating a text-only page for every Web page is twice the work. Invariably, the text version is going to be out of sync with regular content. This then creates an accuracy problem. The accessible version is often hidden behind its inaccessible counterpart. People needing to use the accessible version of the website still need to be able to deal with the inaccessible one. They have to search through an inaccessible page to find the link to the text-only page. This problem could be reduced by ensuring that the "skip to accessible version" link is the first piece of information on a page. Ethan, have you considered making the main site not rely on JavaScript for functionality and having a link to a JavaScript enhanced version, so the accessible version is not hidden behind its inaccessible counterpart?...Or you might want to consider this approach: - make it work without JavaScript - add event handlers or even an AJAX layer to make it work more smoothly - give the user the option to use one interface or the other - as most web apps require login and have a defined user journey this is a lot easier, as visitors are not likely to enter in any of the pages like they do in a web site. Best regards, Laura ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ From barry at python.org Wed Jul 5 22:45:25 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 5 Jul 2006 16:45:25 -0400 Subject: [Mailman-Developers] What I did on my summer vacation Message-ID: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you want to get a taste of the things I'm going to check in soon, please see: http://wiki.list.org/x/vg - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRKwk5nEjvBPtnXfVAQJnOQP+KM/W9bVSRGXmhJkzJOQJHZiMSUNYn4s8 WZ+Dfh6hZGrd2cJRg1Txd7tG+Y8L79Xw0Ln7Y8POFtvFQi5vzl1ni9auPtSJCJa/ 7+Q1ExCCHfrEyBhJO8OBpHvZOHcF8LkGQrfkuj5qshVJbVJNejrfb2xF28tAGXYE Yg2KPopB/8k= =0p35 -----END PGP SIGNATURE----- From i at mindlace.net Thu Jul 6 00:15:07 2006 From: i at mindlace.net (emf) Date: Wed, 05 Jul 2006 18:15:07 -0400 Subject: [Mailman-Developers] Accessible DOM manipulations In-Reply-To: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> Message-ID: <44AC39EB.6020905@mindlace.net> Laura Carlson wrote: > --On Wednesday, July 5, 2006 8:54 PM +0200 emf wrote: > >> Are you suggesting I provide *no* link for the >> screen-reader-with-javascript client and let them at some point >> figure out that they're not seeing what's going on and thus turn off >> javascript? >> >> That seems like a worse solution. > > I'm suggesting that javascript is fine to use for progressive > enhancement but not for core functionality. Laura, I appreciate your thoughtful and detailed replies. I feel like we're kind of talking across each other. I had indicated in a previous post that the mailman interface I am building will be fully functional without javascript/css; it is the first point on the technical plan at http://wiki.list.org/display/DEV/Summer+of+Code . > - make it work without JavaScript > - add event handlers or even an AJAX layer to make it work more smoothly I am not sure what you mean by this. I will be using event handlers, but existing screen readers fire event handlers just fine; in fact they do everything I want them to do *except* change focus to the modified portion of the page. > - give the user the option to use one interface or the other - as most > web apps require login and have a defined user journey this is a lot > easier, as visitors are not likely to enter in any of the pages like > they do in a web site. That is what I was suggesting by providing a link to a js-light version for screen readers. My logic was something like this: Because I am otherwise being quite accessible, someone using a screen reader *with JavaScript enabled* may not realize that some actions are causing other parts of the page to refresh. The javascript code I want to use will be perfectly functional or degrade gracefully otherwise, and I suspect/am working to ensure that they will still provide usability enhancements for those running a javascript interpreter, including said screen readers. One example is keeping extraneous text hidden until it is selected; I imagine that someone using a screen reader/portable device would appreciate being able to read a "overview" page variant and then being able to expand as necessary. Therefore I am attempting to find a solution to this one problem so that I don't have to push screen readers to a JS/css free page unless they choose that. Right this second, it looks like I may be 'safe' if I make sure that whatever DOM manipulations I perform only cause 'downstream' (in code order) elements to become visible/hidden/filled. ~ethan fremen From i at mindlace.net Thu Jul 6 00:37:21 2006 From: i at mindlace.net (emf) Date: Wed, 05 Jul 2006 18:37:21 -0400 Subject: [Mailman-Developers] Parsing and Rendering rfc2822 In-Reply-To: <1152111345.32574.18.camel@finch.boston.redhat.com> References: <44AAC503.9020901@mindlace.net> <1152111345.32574.18.camel@finch.boston.redhat.com> Message-ID: <44AC3F21.1020104@mindlace.net> John Dennis wrote: > It's not at all clear to me that mailman should be responsible for > archiving. While I am somewhat in agreement, the current situation is that archiving comes bundled with mailman and represents a significant weakness in its current web UI. Not doing anything about the web UI presented by the archives would, in my mind, represent a substantial failing. > Archiving and MLM (Mailing List Manager) functionality can be > orthogonal to each other. I can imagine - but have never used - a mailing list where access to past emails is 'orthogonal' to the use of the mailing list. It is hard for me to see the orthogonality except inasmuch as there's often a different user agent involved. > Archiving has a complex feature set if it's > done right, and it's complex to implement. Well, happily mailman is in the situation where archiving is not done right, and it seems like there's room for doing enough to a.) represent an improvement on the current situation and b.) lay a decent groundwork for plugging in different archivers or offering more of this complexity you speak of. > There are many items on Mailman's UI task list which need attention and can be done > independently of also trying to tackle the 800 pound gorilla known as > archiving. I am indeed taking this tack. However, even for things like the moderation approval page I need to parse & render emails. > I seem to > recall this is also Barry's preference who noted the existing pipermail > was only a stop-gap solution so there would be some default archiver, > but it was never the intention Mailman would have any extensive > archiving implementation. Like many stop gap solutions, this one is widely used, and represents the most visited portion of the "mailman web UI". At a bare minimum, the archive pages should provide decent navigation. The requirement for a default archiver remains, and the solution I propose is much more override friendly than the existing one; it wouldn't create hundreds of webpages out of the archives, just read out of the existing mbox files. > For what its worth I went looking for best of breed in open source > archivers about 6 months ago and what I came up with was a project > called "Lurker" (http://lurker.sourceforge.net) Thanks! I will look into this and see what I can glean from it. > IMHO let the archiving experts deal with archiving, let the MLM experts > (e.g. Mailman) deal with managing mailing lists. It is probably just a sign that I haven't explored the extant solutions sufficiently, but I have seen no sign that there are a variety of high-quality archiving solutions out there. What appears to me to be your main point - don't let archiving get in the way of delivering other UI functionality - is well taken; it is not at all at the top of my queue. ~ethan fremen From barry at python.org Thu Jul 6 01:12:45 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 5 Jul 2006 19:12:45 -0400 Subject: [Mailman-Developers] Parsing and Rendering rfc2822 In-Reply-To: <44AC3F21.1020104@mindlace.net> References: <44AAC503.9020901@mindlace.net> <1152111345.32574.18.camel@finch.boston.redhat.com> <44AC3F21.1020104@mindlace.net> Message-ID: <4F339A71-971D-4209-ADBB-0ED98C6D0A53@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 5, 2006, at 6:37 PM, emf wrote: >> I seem to >> recall this is also Barry's preference who noted the existing >> pipermail >> was only a stop-gap solution so there would be some default archiver, >> but it was never the intention Mailman would have any extensive >> archiving implementation. > > Like many stop gap solutions, this one is widely used, and represents > the most visited portion of the "mailman web UI". At a bare > minimum, the > archive pages should provide decent navigation. > > The requirement for a default archiver remains, and the solution I > propose is much more override friendly than the existing one; it > wouldn't create hundreds of webpages out of the archives, just read > out > of the existing mbox files. Pipermail was originally a separate project, developed by Andrew Kuchling IIRC. A looonngg time ago it was integrated into Mailman, but not in a terribly clean way (e.g. inheritance through cut-and- paste). I don't think Andrew's been interested in Pipermail for years. My own position on Pipermail and archiving is that Mailman should come with a default archiver that is minimally useful for simple sites, and that the Python-based Pipermail makes the most sense to serve as this default, simplistic archiver. It keeps packaging, dependencies, and deployment very simple. I'm open to suggestions for alternatives though. (Or ideally, some young college student with lots of free time to devote unending hours to improving Pipermail, at the expense of family, sleep, social life and studies. That, or get Tim Peters interested.) However, it should be very easy to integrate any other archiver with Mailman, and to the extent that current APIs need to be improved, I'm all for that. If you have a pet archiver that requires changes to Mailman to work better, please let us know! Pipermail's lack of a default search feature is its biggest (but by no means only) problem. I'd like to see this addressed, if it can be done cleanly, in MM2.2. I'd favor a Python solution here, for the same reasons as above but again, pluggability would be favored over a hard coded connection. Other than that, it's clear that Pipermail's web u/i is so 1995, and needs a major overhaul. For example, just as you'd like Mailman's web u/i to be easily integrated into the L&F of a site, so too for the Pipermail interface. The major problem with that though is that because Pipermail generates its pages statically, and because of various bugs and misfeatures in earlier versions, any regeneration of the static pages to a new u/i carries with it a high potential to break existing links. Honestly, I don't think there's any good solution to link breakage, so I think the right thing to do is to be able to preserve the current u/i and link algorithm unless the new one is explicitly enabled. And if the archives are regenerated with a new u/i, we should ensure that the link urls will be much more persistent than they currently are, probably based on a guaranteed unique Message-ID or other header-based identifier. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRKxHbXEjvBPtnXfVAQJokwQAsfoFnAp4zBW/1TQXiKqADTf3GIGV1v2u 10NLSlsj11kftf2mSANqTDZvFB/oquzG7f2UBNU1OUtOQhH9guneywLcAnxcmH3o bu1yzcA2dm0AslVPonyg76ps7KERNGK5s4Dw181jlCvjZiyloYi5m+LJhMjQSvNP j4wUyt4CvrI= =j6G0 -----END PGP SIGNATURE----- From barry at python.org Thu Jul 6 01:30:28 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 5 Jul 2006 19:30:28 -0400 Subject: [Mailman-Developers] Parsing and Rendering rfc8222 In-Reply-To: <44AAC503.9020901@mindlace.net> References: <44AAC503.9020901@mindlace.net> Message-ID: <4EF22B7C-0035-49C8-BA55-CDD0EEFD7560@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 4, 2006, at 3:44 PM, emf wrote: > Here's where I'm at, grouped functionally: > > * Need to convert rfc8222 to xml/html > > I haven't found anything substantial via searching. My next step is to > go spelunking in MailManager code and other python-webmail > packages. If > anyone knows good trees in this forest, please clue me in. You might also poke around www.divmod.org and the Chandler project. I believe both of them are in a similar space and there may be components that can be borrowed from those projects to do this kind of thing. > * Want to provide feeds (rss/atom/YourMommasSyntaxFormat) > > Right this second I'm planning on using pyfeed [1]; is there anything > else I should consider? > > [1] http://home.blarg.net/~steveha/pyfeed.html > > * mbox thread indexing on messages > > I plan on using [2] to generate mbox thread indexes for rapid > navigation > of lists. Any suggestions for more robust variants would be welcome; > feedback on how to handle threading for message-id-less messages would > also be welcome. > > [2] http://benno.id.au/code/archiver/jwzthreading.py I haven't looked at either package, but JWZ does have the authoritative word on threading, AFAICT. The question of Message-IDs is the interesting one because it's clearly the most natural unique identifier to use. However, while the RFC says it /should/ be unique, there's actually no guarantee that it /is/ unique, or even present. What should Mailman do if it sees a Message-ID collision? What should it do if there is no Message-ID? It's been argued that Mailman should clobber any Message-ID it sees and just overwrite it with one it can guarantee is unique (for any specific installation, that is). I don't like that solution because of the negative effects on threading when that message is received through Mailman by other systems or applications. It's also been suggested that we just don't worry about it, because the chances of collisions in practice are very small. Yeah, okay, but what if it / does/ happen? Seems like you'd still have to munge Message-ID in that case. It's also been suggested that Mailman assign its own unique identifier whenever it forwards a message to a list membership. I like this the best, and it would have to be called something like X- List-Message-ID or some such. I've long favored a solution where the X-List-Message-ID could be calculated from components of the message that would have a high probability of being immutable, even if a copy of the message was received out-of-band from Mailman. IOW, if an archiver received a message before Mailman could calculate the X-List- Message-ID (or if it received it after some intermediate tool stripped that header), it could perform the same calculation and would end up with the same url, probably using List-Archive in that calculation. I'm thinking something along the lines of sha1 hashing Message-ID and perhaps Date. RFC 2822 $3.6 says that the only required headers are the origination date (Date:) and originator address fields (From: and possibly Sender: and Reply-To:). Those seem like good candidates to base a hash on, but fields like Subject and the body of the message are probably unusable. Then again, we have to watch out for originator header munging. :/ > * full-text indexing > > pylucene seems to be the obvious choice; anything else I should > consider? Anyone know of good pylucene/web UI glue code out there? Just keep in mind that of course, Mailman is GPL so anything we bundle has to be GPL-compatible. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRKxLlXEjvBPtnXfVAQJsBwP/ZvTAHqZaBGA8MR0PH6Oq5c8QCqUBX2tr JjRDT89wQYJqE+dY3tDMrPIytJBKiE50n9usfURzlikq517NG79hYfMMYfZM550K Ua3a9oBrBTzLW+SpEUaM8KT+QakqkDNY3ro6e3KnqUhl3MwwRii9X178m7pYAHRH Sc87Ps/1r8Y= =OH6a -----END PGP SIGNATURE----- From barry at python.org Thu Jul 6 01:33:52 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 5 Jul 2006 19:33:52 -0400 Subject: [Mailman-Developers] Parsing and Rendering rfc8222 In-Reply-To: <34837.72.177.126.107.1152048804.squirrel@mail.his.com> References: <44AAC503.9020901@mindlace.net> <34837.72.177.126.107.1152048804.squirrel@mail.his.com> Message-ID: <0163A9DF-2CEB-48BE-B301-B9F760E14A50@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 4, 2006, at 5:33 PM, Brad Knowles wrote: > Don't ignore non-Python solutions. My main problem with non-Python solutions /as a default for Mailman/ is that it complicates distribution and packaging. It means that we'll have additional dependencies we can't satisfy ourselves, e.g. on other interpreters or on compilers. At least with a pure Python solution, we can package up a distutils thingie and be pretty much assured that it's going to work out of the box. We should certainly do everything we can to make sure that Richard's ht:dig solution is nearly trivial to integrate, but I'm not sure we should distribute it with Mailman. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRKxMYHEjvBPtnXfVAQKQqgP/V82bojemSuFnLGrThmKAS0QBVNvsFsPA IomgATzMERVs8ld+Nwi3QYG41PEMXeuxHGfU3wQqLO4SViS1BepUN1ZUuc9TJ6oM 1M3KmwID4gw5Ra5CjhIBgDjUva7E7OOM/r4/6TWp8pCHuUL/AIf5tjXu5t+NvBvn vfC71BCMrn4= =qAgQ -----END PGP SIGNATURE----- From barry at python.org Thu Jul 6 01:35:57 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 5 Jul 2006 19:35:57 -0400 Subject: [Mailman-Developers] Parsing and Rendering rfc8222 In-Reply-To: References: Message-ID: <5961AFF5-DBCB-4C60-AAB7-4E5D9DC61C5C@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 5, 2006, at 12:30 AM, Mark Sapiro wrote: > Also there is a related issue if A posts, B replies, A replies off > list > to B, and B replies on list. If threading relies solely on References: > or In-Reply-To:, and either A's or B's MUA generates only In-Reply-To, > this thread is broken at the 'missing' post. I don't have any really > good suggestions for alternative threading algorithms however. I think > there was something on this not too long ago on mailman-users or maybe > mailman-developers - I looked and found what I think I remember. The > relevant post is at > 017660.html> > and points to a description of an algorithm at > . I haven't read JWZ's article in a while, but IIRC, it lays out an algorithm that does about as good as you can do in these cases. BTW, my earlier post re: X-List-Message-ID isn't about threading, it's about message identification and trying to make that as robust as possible. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRKxM3XEjvBPtnXfVAQJUhQP/ZXeVZhPYuXMecIMTO6QiPncRuHMZiSAA rpGeYNspQkszVbsLB27nkppfShkJQC8iSMY8WPEssGUJ4guqROtCdJ7hUURUve5D 4uvAizTrl6Kriv82SZPCmUvN12XnfkT5+ENIkwpWEnh5xf4qoQXNqXfAqWX83Y/Y ldDwY+zkltY= =Nhwt -----END PGP SIGNATURE----- From barry at python.org Thu Jul 6 01:40:22 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 5 Jul 2006 19:40:22 -0400 Subject: [Mailman-Developers] Parsing and Rendering rfc8222 In-Reply-To: References: <44AAC503.9020901@mindlace.net> <5F9167F185C38011D2066E27@lewes.staff.uscs.susx.ac.uk> Message-ID: <022A4528-D719-4461-9367-9C7F33995A6F@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 5, 2006, at 10:01 AM, Hans G. Ehrbar wrote: > If mailman would be able to write an xml representation of > each message to a separate file, that would be wonderful. > Then one would be able to use xlst stylesheets to make > custom archives. It's a very interesting idea. How resource intensive would an xslt transformation be if the messages were vended (and rendered) on demand? Many have advocated such on-demand rendering so that things like address obfuscation algorithms could be improved as harvesters catch up. The main argument against this has been server performance (that's certainly the reason Pipermail currently generates static pages), but maybe through judicious caching this could be amortized enough to not crush a server? I could see a global invalidation procedure when something like the obfuscator or a non-stylesheet based layout change was made. Do you have any references for the current state of the art in email XML schemas? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRKxN5nEjvBPtnXfVAQLO1wQAufjZl1Pm7cCLa/Il2zlcdqqPAe4sLzo8 ms1yTaOYaL7z9zB3E0uWv34wZ0+2NZew5WcRnWK8quaOdUYCKQd1TmRzvR7LQa7K e51wMegx+yqsZOtD1Ug/4mBkHJO2zzhi0Z+/d5S0QkGOzyRNkpDPPJszbpYtVRdz xdcnahB1RCY= =e/dx -----END PGP SIGNATURE----- From dandrews at visi.com Thu Jul 6 01:59:45 2006 From: dandrews at visi.com (David Andrews) Date: Wed, 05 Jul 2006 18:59:45 -0500 Subject: [Mailman-Developers] Turning off dynamic JavaScript Message-ID: <7.0.1.0.2.20060705185849.03aa9e88@visi.com> > >There is MSAA, Microsoft Active Accessibility, and a replacement with Vista, I believe, but don't remember what it is called. Don't know if they can be used by style sheets, but inquiry to enable at Microsoft.com might be in order. > >Dave > >At 12:45 PM 7/4/2006, you wrote: >>Gentlebeings, >> >>I have read a depressing and recent article suggesting that DOM >>manipulations are invisible to most screen readers [1]. There are some >>workarounds suggested in [2], but for the most part it looks like >>dangerous territory. >> >>What's worse, there seems to be no way to detect screen readers >>reliably. I am determined to provide some JavaScript in the 'standard' >>interface, as it will make for enhanced ease-of-use for those sighted >>people using a modern browser. >> >>(I think it would be good for screen readers, too, if there was just >>some way for me to control/hint the "focus" of the screen reader, but at >>the moment there doesn't seem to be. Screen readers don't even seem to >>support an aural/speech stylesheet, much less provide some JavaScript >>object that lets me know I'm in one.) >> >>I found a page (that is eluding me at the moment) detailing a method for >>showing content to screen readers yet hiding it from 'regular' clients. >>I was thinking of adding a "Screen Reader Support On" link to the top of >>all pages that would only show to screen readers; does this seem like a >>good approach? >> >>Note that this would be in *addition* to the ability to get a JS-free >>version of the interface by using a different URL prefix for any user >>agent that doesn't want the JS action. >> >>~ethan From dandrews at visi.com Thu Jul 6 02:00:46 2006 From: dandrews at visi.com (David Andrews) Date: Wed, 05 Jul 2006 19:00:46 -0500 Subject: [Mailman-Developers] Fwd: Re: Turning off dynamic JavaScript Message-ID: <7.0.1.0.2.20060705190005.03ae3f10@visi.com> > >I believe there is a "screen reader present" flag in Windows, don't know any more than that. > >Dave > >At 12:59 PM 7/4/2006, you wrote: >>Ethan wrote: >> >>> Note that this would be in *addition* to the ability to get a JS-free >>> version of the interface by using a different URL prefix for any user >>> agent that doesn't want the JS action. >> >>Speaking only for myself, this is not the kind of approach I'd like to see >>used. I'd prefer to see the web application auto-detect that JavaScript >>is not available, and therefore to automatically present the appropriate >>non-JavaScript interface. Likewise, it should auto-detect that there is a >>screen reader being used, and present the appropriate screen reader >>compatible interface. >> >>Of course, the manual options should always be there, but if we're forcing >>the user to manually select a different page in order to get away from the >>JavaScript stuff, then I think we're doing something wrong. >> >>-- >>Brad Knowles, >> >>"Those who would give up essential Liberty, to purchase a little >>temporary Safety, deserve neither Liberty nor Safety." >> >> -- Benjamin Franklin (1706-1790), reply of the Pennsylvania >> Assembly to the Governor, November 11, 1755 >> >> LOPSA member since December 2005. See . >>_______________________________________________ >>Mailman-Developers mailing list >>Mailman-Developers at python.org >>http://mail.python.org/mailman/listinfo/mailman-developers >>Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py >>Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ >>Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/dandrews%40visi.com >> >>Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp >> >>__________ NOD32 1.1617 (20060623) Information __________ >> >>This message was checked by NOD32 antivirus system. >>http://www.eset.com From dandrews at visi.com Thu Jul 6 02:01:41 2006 From: dandrews at visi.com (David Andrews) Date: Wed, 05 Jul 2006 19:01:41 -0500 Subject: [Mailman-Developers] Turning off dynamic JavaScript Message-ID: <7.0.1.0.2.20060705190103.03ac30e8@visi.com> > >I believe that the W3C standards require that Javascript and other components fail gracefully, so the point could be made, for things link Lynx and Links that a graceful degrade would also take care of us screen reader users. Anything specific you write for us, while appreciated, is also something that may have to be kept up separately, and thus may not be. > >Dave > >At 01:06 PM 7/4/2006, you wrote: >>Brad Knowles wrote: >> >>> Speaking only for myself, this is not the kind of approach I'd like to see >>> used. I'd prefer to see the web application auto-detect that JavaScript >>> is not available, and therefore to automatically present the appropriate >>> non-JavaScript interface. >> >>I will do this for browsers not employing JavaScript. Screen readers >>employ JavaScript and provide no indication what they do/do not provide >>feedback to the user for. >> >>> Likewise, it should auto-detect that there is a >>> screen reader being used, and present the appropriate screen reader >>> compatible interface. >> >>This is an admirable goal. One "screen reader" in semi-common use is IE >>6 via Jaws; another one is Safari with OS X reading turned on. >> >>They present to me no handle, user-agent or otherwise, indicating >>they're being spoken rather than seen. >> >>> Of course, the manual options should always be there, but if we're forcing >>> the user to manually select a different page in order to get away from the >>> JavaScript stuff, then I think we're doing something wrong. >> >>I agree that it is an Ugly Hack; In this case I think the screen readers >>are misbehaved, but there's not a lot I can do about that. >> >>~ethan fremen >> >>_______________________________________________ >>Mailman-Developers mailing list >>Mailman-Developers at python.org >>http://mail.python.org/mailman/listinfo/mailman-developers >>Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py >>Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ >>Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/dandrews%40visi.com >> >>Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp >> >>__________ NOD32 1.1617 (20060623) Information __________ >> >>This message was checked by NOD32 antivirus system. >>http://www.eset.com From jwblist3 at olympus.net Thu Jul 6 02:04:16 2006 From: jwblist3 at olympus.net (John W. Baxter) Date: Wed, 05 Jul 2006 17:04:16 -0700 Subject: [Mailman-Developers] Parsing and Rendering rfc8222 In-Reply-To: <4EF22B7C-0035-49C8-BA55-CDD0EEFD7560@python.org> Message-ID: On 7/5/06 4:30 PM, "Barry Warsaw" wrote: > I'm thinking something along the lines of sha1 hashing Message-ID and > perhaps Date. RFC 2822 $3.6 says that the only required headers are > the origination date (Date:) and originator address fields (From: and > possibly Sender: and Reply-To:). One does see messages with no Date: header. In the past, one also saw messages with multiple Date: headers. (Neither condition complies with RFCs.) I suspect in that case the hash would include some convenient constant. (I can't remember where I saw the multiple Date: header form--it might have been from Western Union (or not)). I was examining Date: headers because of the bug in old Exchange + Outlook combinations in which a crafted overlength Date: header could cause viral infections if the message were simply present in a mailbox list display created by Outlook. (Around 1966 or so, but of course those versions have to be in use together somewhere still--it's only a decade.) --John From dandrews at visi.com Thu Jul 6 02:07:40 2006 From: dandrews at visi.com (David Andrews) Date: Wed, 05 Jul 2006 19:07:40 -0500 Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: References: <44AC045F.9030908@mindlace.net> Message-ID: <7.0.1.0.2.20060705190630.00bddb08@visi.com> That assertion is not true, to my knowledge -- and I am a screen reader user. Because it does work with a lot of things, and does offer improved functionality, it is rare to turn Javascript off. David Andrews At 01:54 PM 7/5/2006, John W. Baxter wrote: >On 7/5/06 11:26 AM, "emf" wrote: > >> The problem I face is not when JavaScript is not active, the problem is >> when JavaScript *is* active *and* behaves correctly - i.e. performs the >> dom modification I've told it to - but the browser/screen reader doesn't >> bother to tell the user. >> >> ~ethan fremen > >Does the industry (I almost wrote "do we") know how big a problem this is in >practice? That is, what fraction of users of screen readers and other >assistive stuff routinely run with JavaScript active? > >Since the assertion here is "screenreaders have trouble with JavaScript" I >would expect most screenreader users to have JavaScript turned off. > > --John > > >_______________________________________________ >Mailman-Developers mailing list >Mailman-Developers at python.org >http://mail.python.org/mailman/listinfo/mailman-developers >Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py >Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ >Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/dandrews%40visi.com > >Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp > >__________ NOD32 1.1617 (20060623) Information __________ > >This message was checked by NOD32 antivirus system. >http://www.eset.com From ulisavi at tin.it Thu Jul 6 04:24:34 2006 From: ulisavi at tin.it (Ulisse Savi) Date: Thu, 6 Jul 2006 04:24:34 +0200 Subject: [Mailman-Developers] Strange words that don't exists in Wikipedia and MonoBook.tpl the output continue to be identical ? Message-ID: <001201c6a0a3$52cd2f90$02e7fea9@ullo> I have installed a mirror of Wikipedia in my site here : http://encyclopedia.meta99.com/ But i have some problems. I never used MediaWiki in past and i'm a newbie. Can you help me ? 1) Some pages has strange words that don't exists in Wikipedia- For example the "Cats" page and the "Dogs page" : http://encyclopedia.meta99.com/wiki/Dogs http://encyclopedia.meta99.com/wiki/Cats has strange words in the page : {{#if:| [[{{{diversity_link}}}|Diversity]]}} {{#if:| Binomial name {{{binomial}}}}} {{#if:Felis silvestris catus| Trinomial name Felis silvestris catus(Linnaeus, 1758)}} {{#if:| Type Genus {{{type_genus}}}}} {{#if:| Type Species {{{type_species}}}}} {{#if:| [[image:{{{range_map}}}|200px|]]}} {{#if:| {{{binomial2}}}}} {{#if:| {{{trinomial2}}}}} {{#if:| [[image:{{{range_map2}}}|200px|]]}} {{#if:| {{{binomial3}}}}} {{#if:| {{{trinomial3}}}}} {{#if:| [[image:{{{range_map3}}}|200px|]]}} {{#if:| {{{binomial4}}}}} {{#if:| {{{trinomial4}}}}} {{#if:| [[image:{{{range_map4}}}|200px|]]}} {{#if:| {{{subdivision_ranks}}}}} {{#if:| Why these terrible words ? Exist a setting to disable the words in the output ? 2) I do not understand where is the system to change the output template/skin. I have changed some file in the directory /skins/ . For example the MonoBook.tpl but the output continue to be the same. If i change the directly the MonoBook.tpl file in the directory /skins/ why the output is identical ? A problem of cache ? I need ro change the html output to make it similar to my other pages different from MediaWiki. But i have failed to change the template. Why if i change directly MonoBook.tpl the output continue to be identical ? From ulisavi at tin.it Thu Jul 6 04:32:55 2006 From: ulisavi at tin.it (Ulisse Savi) Date: Thu, 6 Jul 2006 04:32:55 +0200 Subject: [Mailman-Developers] Strange words that don't exists in Wikipediaand MonoBook.tpl the output continue to be identical ? References: <001201c6a0a3$52cd2f90$02e7fea9@ullo> Message-ID: <005d01c6a0a4$7d02e420$02e7fea9@ullo> I MADE AN ERROR WITH ANOTHER MAILING LIST I have posted the message in mailman-developers at python.org and not in wikitech-l at wikimedia.org PARDON ME From lcarlson at d.umn.edu Thu Jul 6 14:24:12 2006 From: lcarlson at d.umn.edu (Laura Carlson) Date: Thu, 06 Jul 2006 05:24:12 -0700 Subject: [Mailman-Developers] Mailman-Developers Digest, Vol 207, Issue 6 In-Reply-To: References: Message-ID: --On Thursday, July 06, 2006 1:30 AM +0200 emf wrote: > I had indicated in a > previous post that the mailman interface I am building > will be fully > functional without javascript/css; Excellent, Ethan. Sorry for the confusion. Thanks for all of your hard work. All the Best, Laura ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ From lcarlson at d.umn.edu Thu Jul 6 14:26:42 2006 From: lcarlson at d.umn.edu (Laura Carlson) Date: Thu, 06 Jul 2006 05:26:42 -0700 Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: References: Message-ID: <5EE58E388F899419EBD81A71@dial34-11.d.umn.edu> --On Thursday, July 06, 2006 1:30 AM +0200 emf wrote: > I had indicated in a > previous post that the mailman interface I am building > will be fully > functional without javascript/css; Excellent, Ethan. Sorry for the confusion. Thanks for all of your hard work. All the Best, Laura ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ From i at mindlace.net Thu Jul 6 16:55:25 2006 From: i at mindlace.net (emf) Date: Thu, 06 Jul 2006 10:55:25 -0400 Subject: [Mailman-Developers] email schemas In-Reply-To: References: <44AAC503.9020901@mindlace.net> <5F9167F185C38011D2066E27@lewes.staff.uscs.susx.ac.uk> Message-ID: <44AD245D.3020804@mindlace.net> Hans G. Ehrbar wrote: > If mailman would be able to write an xml representation of > each message to a separate file, that would be wonderful. > Then one would be able to use xlst stylesheets to make > custom archives. I've looked into this a bit, and so far have found only a few schema-like things for email, and the ones I've found make each header an element. It seems to me like perhaps one would not want that arbitrariness and would instead prefer something like: Where the standard headers are their own elements but the extended ones have their names in an attribute. Looking at a few python projects that display mail, they mostly seem to use the email module and then pull out the parts they're interested in. In order to provide a feed interface/ decent moderation interface, I have to have something analogous to this; while I don't intend to write each mail out as xml, there should be an url you can tickle to get out an xml representation. ~ethan From jwblist3 at olympus.net Thu Jul 6 17:07:37 2006 From: jwblist3 at olympus.net (John W. Baxter) Date: Thu, 06 Jul 2006 08:07:37 -0700 Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: <7.0.1.0.2.20060705190630.00bddb08@visi.com> Message-ID: Thank you for the correction, David. --John On 7/5/06 5:07 PM, "David Andrews" wrote: > That assertion is not true, to my knowledge -- and I am a screen reader user. > Because it does work with a lot of things, and does offer improved > functionality, it is rare to turn Javascript off. > > David Andrews > > At 01:54 PM 7/5/2006, John W. Baxter wrote: >> On 7/5/06 11:26 AM, "emf" wrote: >> >>> The problem I face is not when JavaScript is not active, the problem is >>> when JavaScript *is* active *and* behaves correctly - i.e. performs the >>> dom modification I've told it to - but the browser/screen reader doesn't >>> bother to tell the user. >>> >>> ~ethan fremen >> >> Does the industry (I almost wrote "do we") know how big a problem this is in >> practice? That is, what fraction of users of screen readers and other >> assistive stuff routinely run with JavaScript active? >> >> Since the assertion here is "screenreaders have trouble with JavaScript" I >> would expect most screenreader users to have JavaScript turned off. >> >> --John From jdennis at redhat.com Thu Jul 6 17:30:08 2006 From: jdennis at redhat.com (John Dennis) Date: Thu, 06 Jul 2006 11:30:08 -0400 Subject: [Mailman-Developers] email schemas In-Reply-To: <44AD245D.3020804@mindlace.net> References: <44AAC503.9020901@mindlace.net> <5F9167F185C38011D2066E27@lewes.staff.uscs.susx.ac.uk> <44AD245D.3020804@mindlace.net> Message-ID: <1152199808.32574.88.camel@finch.boston.redhat.com> On Thu, 2006-07-06 at 10:55 -0400, emf wrote: > Hans G. Ehrbar wrote: > > If mailman would be able to write an xml representation of > > each message to a separate file, that would be wonderful. > > Then one would be able to use xlst stylesheets to make > > custom archives. > > I've looked into this a bit, and so far have found only a few > schema-like things for email, and the ones I've found make each header > an element. It seems to me like perhaps one would not want that > arbitrariness and would instead prefer something like: > > > > > > > > Where the standard headers are their own elements but the extended ones > have their names in an attribute. I'm not sure I understand what the purpose is in treating the extended fields differently, it seems like it would overly complicate the xml navigation without any clear advantage. Anyone who is interested in the value of an extended field will know it by name and ask for it by name just like the defined fields. Here I'm assuming the query will be performed via either by evaluating an XPath expression (either via xlst or via a procedural call, e.g. libxml2), or by navigating a DOM tree via a number of DOM libraries or via an event driven SAX parsing library. In all these cases I would imagine uniformly accessing the field by it's element name without special casing the element name would be the desired approach. I'm sure you realize this, but you'll want to preserve the ordering of the mail header fields when you generate the XML document. > Looking at a few python projects that display mail, they mostly seem to > use the email module and then pull out the parts they're interested in. > > In order to provide a feed interface/ decent moderation interface, I > have to have something analogous to this; while I don't intend to write > each mail out as xml, there should be an url you can tickle to get out > an xml representation. -- John Dennis Red Hat Inc. From iane at sussex.ac.uk Thu Jul 6 18:24:43 2006 From: iane at sussex.ac.uk (Ian Eiloart) Date: Thu, 06 Jul 2006 17:24:43 +0100 Subject: [Mailman-Developers] email schemas In-Reply-To: <1152199808.32574.88.camel@finch.boston.redhat.com> References: <44AAC503.9020901@mindlace.net> <5F9167F185C38011D2066E27@lewes.staff.uscs.susx.ac.uk> <44AD245D.3020804@mindlace.net> <1152199808.32574.88.camel@finch.boston.redhat.com> Message-ID: <87438C7E29D9D8A15525A228@lewes.staff.uscs.susx.ac.uk> --On 6 July 2006 11:30:08 -0400 John Dennis wrote: > I'm not sure I understand what the purpose is in treating the extended > fields differently, it seems like it would overly complicate the xml > navigation without any clear advantage. Anyone who is interested in the > value of an extended field will know it by name and ask for it by name > just like the defined fields. I think the problem is that you can't define them in the schema. With ethan's mechanism, you just have to define one tag - x-header. -- Ian Eiloart IT Services, University of Sussex From iane at sussex.ac.uk Thu Jul 6 18:46:21 2006 From: iane at sussex.ac.uk (Ian Eiloart) Date: Thu, 06 Jul 2006 17:46:21 +0100 Subject: [Mailman-Developers] test addresses Message-ID: Hi, I was just discussing Mailman features with our user-support person. One idea we had (not directly related to the web interface) is a test address for every list. The purpose is to test a list setup without spamming everyone. So, if we had a list foo at example.com, it would be nice to be able to send an email to foo-test at example.com and get back an email saying what would have happened if I'd emailed the list. The result might be a standard bounce, but alternatively, it might say "your email was accepted, and would have been delivered to 16 addresses, including 4 other Mailman lists on this server. 3 other recipients have no-mail set". Where a list member is another Mailman list on the same server, that list should be sent an email to its test address, and so on, recursively. Of course, if the new interface manages to be sufficiently simple and robust, the need for test addresses might be reduced. -- Ian Eiloart IT Services, University of Sussex From jdennis at redhat.com Thu Jul 6 19:10:40 2006 From: jdennis at redhat.com (John Dennis) Date: Thu, 06 Jul 2006 13:10:40 -0400 Subject: [Mailman-Developers] email schemas In-Reply-To: <87438C7E29D9D8A15525A228@lewes.staff.uscs.susx.ac.uk> References: <44AAC503.9020901@mindlace.net> <5F9167F185C38011D2066E27@lewes.staff.uscs.susx.ac.uk> <44AD245D.3020804@mindlace.net> <1152199808.32574.88.camel@finch.boston.redhat.com> <87438C7E29D9D8A15525A228@lewes.staff.uscs.susx.ac.uk> Message-ID: <1152205840.32574.137.camel@finch.boston.redhat.com> On Thu, 2006-07-06 at 17:24 +0100, Ian Eiloart wrote: > > --On 6 July 2006 11:30:08 -0400 John Dennis wrote: > > > I'm not sure I understand what the purpose is in treating the extended > > fields differently, it seems like it would overly complicate the xml > > navigation without any clear advantage. Anyone who is interested in the > > value of an extended field will know it by name and ask for it by name > > just like the defined fields. > > I think the problem is that you can't define them in the schema. With > ethan's mechanism, you just have to define one tag - x-header. O.K. that makes sense, but I guess it boils down to a design choice. 1) Well defined DTD/Schema, but awkward to use in practice. 2) Easy to use, but no standardized DTD/Schema to be used for validation. Most literature on XML concedes there is quite a bit of give and take in XML design which needs to be flexible and take into consideration a host of factors. Most authors suggest strict DTD/Schema is mostly appropriate for documents with complex structure or where the document receiver has no apriori knowledge of the document structure. I don't think either of these apply in this circumstance. I think the document structure is extremely simple, a head element which contains one level of child elements. Like I said, it's a design choice, each has their merits. In this case my vote would be for simplicity and ease of use over rigor. BTW, is the intention this XML document is going to have full blown parsing all the way through all the mime (sub)parts? The answer to that question probably drives how much rigor is appropriate. -- John Dennis Red Hat Inc. From lcarlson at d.umn.edu Thu Jul 6 18:30:49 2006 From: lcarlson at d.umn.edu (Laura Carlson) Date: Thu, 06 Jul 2006 11:30:49 -0500 Subject: [Mailman-Developers] Turning off dynamic JavaScript In-Reply-To: References: Message-ID: At 01:54 PM 7/5/2006, John W. Baxter wrote: >> Does the industry (I almost wrote "do we") know how big a problem >> this is in practice? That is, what fraction of users of screen >> readers and other assistive stuff routinely run with JavaScript >> active? >> >> Since the assertion here is "screenreaders have trouble with >> JavaScript" I would expect most screenreader users to have >> JavaScript turned off. >> >> --John At 01:54 PM 7/5/2006, David Andrews wrote: > That assertion is not true, to my knowledge -- and I am a screen > reader user. Because it does work with a lot of things, and does > offer improved functionality, it is rare to turn Javascript off. > > David Andrews On one of the SXSW 2006 Interactive Panels [1], "Making Web 2.0 Accessible", Javascript and accessibility guru, Derek Featherstone, mentioned that screenreaders running with JavaScript enabled is in fact the norm. Shawn Henry also mention the importance of testing with users. Laura SXSW 2006 Podcasts: [1] http://2006.sxsw.com/coverage/podcasts/ ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ From i at mindlace.net Thu Jul 6 19:19:22 2006 From: i at mindlace.net (emf) Date: Thu, 06 Jul 2006 13:19:22 -0400 Subject: [Mailman-Developers] Users, persistent storage, caches, etc. In-Reply-To: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> References: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> Message-ID: <44AD461A.1020902@mindlace.net> Barry et. al.: Barry, I've read about your SQLAlchemy work and look forward to seeing that checkin ;) Here's my situation: 1.) I have to have a concept of user to really improve the user interface. Many things become easier, but there are things I can do with a user-concept I can't do without it: a.) Different emails for different lists, same user. b.) Providing moderator/admin privileges to a user rather than a shared secret. 2.) I need to store preference information somewheres. This includes: site-wide UI configuration; list-wide UI configuration; user UI preferences/state. 3.) I need to store caches somewhere; for some things it would be best to keep them around, and maybe even in a more queryable format than files. All of this leads me to- where should I stick things? ~ethan From i at mindlace.net Thu Jul 6 19:29:43 2006 From: i at mindlace.net (emf) Date: Thu, 06 Jul 2006 13:29:43 -0400 Subject: [Mailman-Developers] email schemas In-Reply-To: <1152205840.32574.137.camel@finch.boston.redhat.com> References: <44AAC503.9020901@mindlace.net> <5F9167F185C38011D2066E27@lewes.staff.uscs.susx.ac.uk> <44AD245D.3020804@mindlace.net> <1152199808.32574.88.camel@finch.boston.redhat.com> <87438C7E29D9D8A15525A228@lewes.staff.uscs.susx.ac.uk> <1152205840.32574.137.camel@finch.boston.redhat.com> Message-ID: <44AD4887.9050209@mindlace.net> John Dennis wrote: > O.K. that makes sense, but I guess it boils down to a design choice. > > 1) Well defined DTD/Schema, but awkward to use in practice. Another approach would be something like:
To bob at dobbs.org
...
X-Foo blarg
I'm not against that. > 2) Easy to use, but no standardized DTD/Schema to be used for > validation. Well, schemas have the singular merit of being able to loosely specify something, so you could still have a schema, just not a DTD. It also is problematic to have an arbitrary set of tags; I can imagine someone using characters illegal for element names in an X-header. The above approach has the advantage of keeping things safely in CDATA segments, so it's probably better than attributes. > Most authors suggest strict DTD/Schema is mostly appropriate > for documents with complex structure or where the document receiver has > no apriori knowledge of the document structure. I don't think either of > these apply in this circumstance. As I understand it, any user agent is free to throw on any X-header their little heart desires, so that strikes me as a lack of a-priori knowledge. For archiving/moderation purposes, we must accept anything that mailman does. > BTW, is the intention this XML document is going to have full blown > parsing all the way through all the mime (sub)parts? I was angling for something along those lines, yes. ~ethan fremen From brad at stop.mail-abuse.org Thu Jul 6 19:38:29 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 6 Jul 2006 13:38:29 -0400 (EDT) Subject: [Mailman-Developers] Accessible DOM manipulations In-Reply-To: <44AC39EB.6020905@mindlace.net> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> Message-ID: <33390.72.177.126.107.1152207509.squirrel@mail.his.com> Ethan wrote: > One example is keeping extraneous text hidden until it is selected; I > imagine that someone using a screen reader/portable device would > appreciate being able to read a "overview" page variant and then being > able to expand as necessary. I would much prefer to do this without JavaScript. Because you can't guarantee that you know the way that page would be rendered if you send all sorts of "hidden" text that isn't shown until such time as someone does something to make it appear, and you can't control what kinds of mailicious cross-scripting attacks people may throw at you, it's best to simply not send anything that the user cannot currently see. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From maxb1 at ukf.net Thu Jul 6 19:14:52 2006 From: maxb1 at ukf.net (Max Bowsher) Date: Thu, 06 Jul 2006 18:14:52 +0100 Subject: [Mailman-Developers] What I did on my summer vacation In-Reply-To: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> References: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> Message-ID: <44AD450C.1090907@ukf.net> Barry Warsaw wrote: > If you want to get a taste of the things I'm going to check in soon, > please see: > > http://wiki.list.org/x/vg Seems to require you to register and log in merely to view it... shouldn't anonymous viewing be allowed? Max. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: OpenPGP digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060706/a9627c0d/attachment.pgp From barry at python.org Thu Jul 6 19:44:16 2006 From: barry at python.org (Barry Warsaw) Date: Thu, 6 Jul 2006 13:44:16 -0400 Subject: [Mailman-Developers] What I did on my summer vacation In-Reply-To: <44AD450C.1090907@ukf.net> References: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> <44AD450C.1090907@ukf.net> Message-ID: <1028C573-4A18-4F62-98A5-BC15F28D09C2@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 6, 2006, at 1:14 PM, Max Bowsher wrote: > Barry Warsaw wrote: >> If you want to get a taste of the things I'm going to check in soon, >> please see: >> >> http://wiki.list.org/x/vg > > > Seems to require you to register and log in merely to view it... > shouldn't anonymous viewing be allowed? yes, definitely. I haven't figured out how to do that yet, but I'll keep looking. My intention is that (nearly) all of the wiki should be readable anonymously, but you'll have to log in to write to it (to reduce the wikispam). - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK1L8HEjvBPtnXfVAQJ9PwQAt5p36p809H2IYUbV8pm3HECHLNUCB0cL 1nJZN1vG70Iey0wZWP0B6gdmIb6E677F6Q/gwRkHRnhiub5OGwpYohRMBZWwh+Rz lFUeJCRcqyrc9vm3QxqFrVWlgEuw0sI1XrqkT+7bHxDcTiS7ZLRg//ck8dMsnOFI dDVwNBrPbio= =K8jH -----END PGP SIGNATURE----- From brad at stop.mail-abuse.org Thu Jul 6 19:45:47 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 6 Jul 2006 13:45:47 -0400 (EDT) Subject: [Mailman-Developers] Parsing and Rendering rfc2822 In-Reply-To: <44AC3F21.1020104@mindlace.net> References: <44AAC503.9020901@mindlace.net> <1152111345.32574.18.camel@finch.boston.redhat.com> <44AC3F21.1020104@mindlace.net> Message-ID: <33408.72.177.126.107.1152207947.squirrel@mail.his.com> Ethan quoted John Dennis: >> It's not at all clear to me that mailman should be responsible for >> archiving. > > While I am somewhat in agreement, the current situation is that > archiving comes bundled with mailman and represents a significant > weakness in its current web UI. Not doing anything about the web UI > presented by the archives would, in my mind, represent a substantial > failing. One of the reasons I switched from Majordomo to Mailman was because of the better integration of the web control and archive system, so I at least partially agree with you. >> Archiving and MLM (Mailing List Manager) functionality can be >> orthogonal to each other. > > I can imagine - but have never used - a mailing list where access to > past emails is 'orthogonal' to the use of the mailing list. Majordomo, older versions of Mailman, as just two examples of many. In fact, most MLMs don't necessarily have integrated archive components. And there are plenty of people who don't care for Pipermail and instead integrate a third-party archive system into Mailman, in accordance with the instructions that we provide in the FAQ Wizard. I am not at all opposed to improving or replacing pipermail with something else that is integrated into Mailman, but we need to make sure we don't lose sight of these other archive systems, and that we don't do anything that would make it more difficult to use them. > It is probably just a sign that I haven't explored the extant solutions > sufficiently, but I have seen no sign that there are a variety of > high-quality archiving solutions out there. There are at least a couple of alternatives mentioned in the FAQ Wizard, and John has clearly found at least one more. I'm sure he can tell you the search process he used to find all the others, so that you can take a look at all the ones he found and then see if there are any others you can discover on top of that. But this is a pretty big undertaking. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From carbonnb at gmail.com Thu Jul 6 19:46:35 2006 From: carbonnb at gmail.com (Bryan Carbonnell) Date: Thu, 6 Jul 2006 13:46:35 -0400 Subject: [Mailman-Developers] Accessible DOM manipulations In-Reply-To: <33390.72.177.126.107.1152207509.squirrel@mail.his.com> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> Message-ID: On 7/6/06, Brad Knowles wrote: > Ethan wrote: > > > One example is keeping extraneous text hidden until it is selected; I > > imagine that someone using a screen reader/portable device would > > appreciate being able to read a "overview" page variant and then being > > able to expand as necessary. > > I would much prefer to do this without JavaScript. Because you can't > guarantee that you know the way that page would be rendered if you send > all sorts of "hidden" text that isn't shown until such time as someone > does something to make it appear, and you can't control what kinds of > mailicious cross-scripting attacks people may throw at you, it's best to > simply not send anything that the user cannot currently see. I have to agree with Brad on this. An option may be to give the site admin the ability to turn the JS on/off site wide with a mm_cfg.py variable. -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From brad at stop.mail-abuse.org Thu Jul 6 19:56:41 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 6 Jul 2006 13:56:41 -0400 (EDT) Subject: [Mailman-Developers] Parsing and Rendering rfc8222 In-Reply-To: <0163A9DF-2CEB-48BE-B301-B9F760E14A50@python.org> References: <44AAC503.9020901@mindlace.net> <34837.72.177.126.107.1152048804.squirrel@mail.his.com> <0163A9DF-2CEB-48BE-B301-B9F760E14A50@python.org> Message-ID: <33514.72.177.126.107.1152208601.squirrel@mail.his.com> Barry said: > We should certainly do everything we can to make sure that Richard's > ht:dig solution is nearly trivial to integrate, but I'm not sure we > should distribute it with Mailman. Sorry, I guess I wasn't clear -- I just meant for him to look at both Python and non-Python solutions, before deciding what was going to be done and how. I wasn't advocating the incorporation of ht:dig itself into the stuff we ship. At least, I didn't mean for it to come off that way. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From jdennis at redhat.com Thu Jul 6 20:09:18 2006 From: jdennis at redhat.com (John Dennis) Date: Thu, 06 Jul 2006 14:09:18 -0400 Subject: [Mailman-Developers] email schemas In-Reply-To: <44AD4887.9050209@mindlace.net> References: <44AAC503.9020901@mindlace.net> <5F9167F185C38011D2066E27@lewes.staff.uscs.susx.ac.uk> <44AD245D.3020804@mindlace.net> <1152199808.32574.88.camel@finch.boston.redhat.com> <87438C7E29D9D8A15525A228@lewes.staff.uscs.susx.ac.uk> <1152205840.32574.137.camel@finch.boston.redhat.com> <44AD4887.9050209@mindlace.net> Message-ID: <1152209358.32574.168.camel@finch.boston.redhat.com> On Thu, 2006-07-06 at 13:29 -0400, emf wrote: Pardon my top post, these are all good points Ethan, it's clear you've given it careful thought. > Another approach would be something like: >
To bob at dobbs.org
Yeah, that would work too, but it's a little awkward, I like your original idea better. > It also is problematic to have an arbitrary set of tags; I can imagine > someone using characters illegal for element names in an X-header. Good thinking, the legal character set differs between the two RFC's. > As I understand it, any user agent is free to throw on any X-header > their little heart desires, so that strikes me as a lack of a-priori > knowledge. No problem, silently ignore unknown fields. > > BTW, is the intention this XML document is going to have full blown > > parsing all the way through all the mime (sub)parts? > > I was angling for something along those lines, yes. Hmm... then you'll have to introduce the same structure for handling extended mime types etc., consistency in structural representation is probably a good thing. Since you'll going to have to deal with unknown names I think I would prefer both well known names and unknown extended names have identical document structure rather than special casing the extended names in an independent way. Special casing during a document traversal based on context introduces unnecessary pain. -- John Dennis Red Hat Inc. From t.d.lee at durham.ac.uk Thu Jul 6 20:11:20 2006 From: t.d.lee at durham.ac.uk (David Lee) Date: Thu, 6 Jul 2006 19:11:20 +0100 (BST) Subject: [Mailman-Developers] Users, persistent storage, caches, etc. In-Reply-To: <44AD461A.1020902@mindlace.net> References: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> <44AD461A.1020902@mindlace.net> Message-ID: On Thu, 6 Jul 2006, emf wrote: > Barry et. al.: > > Barry, I've read about your SQLAlchemy work and look forward to seeing > that checkin ;) > > Here's my situation: > > 1.) I have to have a concept of user to really improve the user > interface. Many things become easier, but there are things I can do with > a user-concept I can't do without it: > > a.) Different emails for different lists, same user. > b.) Providing moderator/admin privileges to a user rather than a shared > secret. > > 2.) I need to store preference information somewheres. This includes: > site-wide UI configuration; list-wide UI configuration; user UI > preferences/state. > > 3.) I need to store caches somewhere; for some things it would be best > to keep them around, and maybe even in a more queryable format than files. > > All of this leads me to- where should I stick things? +1 please! I locally need (and am actively working on) a sender-based authorisation scheme. This is like "Approve:", but whose password is associated with the (claimed) sender, rather than the list. This, too needs a persistent storage scheme for site-wide users and their passwords. I've had to devise my own (very simple!) scheme for creating and managing a user database of email-address and password. (In our context, at present, this could just about be managed by Mailman admin staff, using a command-line utility, but expansion to user-based self-maintenance, and via the WWW interface would be desirable.) So it sounds as if at least two of us (Ethan and me) are actively looking at implementing similar functionality (albeit initially for different 'local' reasons). So a clear steer from the Mailman seers and soothsayers would be most welcome so that Ethan's work and my work can aim in the same direction as anticipated Mailman 'futures'. Indeed, if the Mailman folk happen already to have a sketch of a user-database scheme, that could be most useful to us... (Or Ethan: I'd be interested in tracking any work you do in this area!) -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : From jdennis at redhat.com Thu Jul 6 20:17:33 2006 From: jdennis at redhat.com (John Dennis) Date: Thu, 06 Jul 2006 14:17:33 -0400 Subject: [Mailman-Developers] Parsing and Rendering rfc2822 In-Reply-To: <33408.72.177.126.107.1152207947.squirrel@mail.his.com> References: <44AAC503.9020901@mindlace.net> <1152111345.32574.18.camel@finch.boston.redhat.com> <44AC3F21.1020104@mindlace.net> <33408.72.177.126.107.1152207947.squirrel@mail.his.com> Message-ID: <1152209853.32574.175.camel@finch.boston.redhat.com> On Thu, 2006-07-06 at 13:45 -0400, Brad Knowles wrote: > [ snip discussion of fixing pipermail and alternate archivers ] > But this is a pretty big undertaking. I'm 100% with Brad on this, this is a huge chunk of work, probably a project in its own regard. Would you really finish this during your summer of code? You've got great ideas, but be realistic about what you can actually accomplish and don't forget for those folks who dislike pipermail one can with minimal effort use an external archiver. -- John Dennis Red Hat Inc. From jdennis at redhat.com Thu Jul 6 20:33:55 2006 From: jdennis at redhat.com (John Dennis) Date: Thu, 06 Jul 2006 14:33:55 -0400 Subject: [Mailman-Developers] Users, persistent storage, caches, etc. In-Reply-To: References: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> <44AD461A.1020902@mindlace.net> Message-ID: <1152210835.32574.191.camel@finch.boston.redhat.com> > On Thu, 6 Jul 2006, emf wrote: > > > Barry, I've read about your SQLAlchemy work and look forward to seeing > > that checkin ;) > > > > 1.) I have to have a concept of user to really improve the user > > interface. ... My apologies, I have yet to read Barry's SQL work so perhaps the issue of how a user is defined has been greatly enhanced over the current 2.1 model. But from earlier work I did on "adapters" I can say Ethan is right on with respect to needing per-list information on a user, rather than just a global user. Perhaps the right model is a hierarchical resolution of attributes, e.g. Does this list force an override of this attribute?, else Does the site force an override of this attribute?, else Is the attribute defined for this user for this list?, else Is the attribute defined in the user's global properties?, else Is the attribute defined for the list?, else Is the attribute defined in the site's global properties?, else attribute is undefined -- John Dennis Red Hat Inc. From jdennis at redhat.com Thu Jul 6 20:45:53 2006 From: jdennis at redhat.com (John Dennis) Date: Thu, 06 Jul 2006 14:45:53 -0400 Subject: [Mailman-Developers] Parsing and Rendering rfc2822 In-Reply-To: <1152209853.32574.175.camel@finch.boston.redhat.com> References: <44AAC503.9020901@mindlace.net> <1152111345.32574.18.camel@finch.boston.redhat.com> <44AC3F21.1020104@mindlace.net> <33408.72.177.126.107.1152207947.squirrel@mail.his.com> <1152209853.32574.175.camel@finch.boston.redhat.com> Message-ID: <1152211553.32574.202.camel@finch.boston.redhat.com> On Thu, 2006-07-06 at 14:17 -0400, John Dennis wrote: > ... don't forget for those folks who dislike > pipermail one can with minimal effort use an external archiver. Oh, and I should have added that one of the beefs with using an external archiver is the disjoint UI between mailman and the archiver, the look and feel and be very different. But since you're adding support for stylesheets with mailman this issue is minimized, external archivers become that much more attractive because it's easier to unify the look and feel. Speaking of stylesheets and customized UI, are you planning on having the core mailman code generate xml, which then is transformed with xslt? This might be more flexible than relying on javascript to control what is presented to the user. Sites can then replace the xslt if need be. Javascript still has a very valuable role to play and I'm not suggesting not using it, but rather introducing an xslt transform means there would be very little a site could not customize without ever touching mailman internals. -- John Dennis Red Hat Inc. From t.d.lee at durham.ac.uk Thu Jul 6 21:02:52 2006 From: t.d.lee at durham.ac.uk (David Lee) Date: Thu, 6 Jul 2006 20:02:52 +0100 (BST) Subject: [Mailman-Developers] Users, persistent storage, caches, etc. In-Reply-To: <1152210835.32574.191.camel@finch.boston.redhat.com> References: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> <44AD461A.1020902@mindlace.net> <1152210835.32574.191.camel@finch.boston.redhat.com> Message-ID: On Thu, 6 Jul 2006, John Dennis wrote: > > On Thu, 6 Jul 2006, emf wrote: > > > > > Barry, I've read about your SQLAlchemy work and look forward to seeing > > > that checkin ;) > > > > > > 1.) I have to have a concept of user to really improve the user > > > interface. ... > > My apologies, I have yet to read Barry's SQL work so perhaps the issue > of how a user is defined has been greatly enhanced over the current 2.1 > model. But from earlier work I did on "adapters" I can say Ethan is > right on with respect to needing per-list information on a user, rather > than just a global user. Perhaps the right model is a hierarchical > resolution of attributes, e.g. > > Does this list force an override of this attribute?, else > > Does the site force an override of this attribute?, else > > Is the attribute defined for this user for this list?, else > > Is the attribute defined in the user's global properties?, else > > Is the attribute defined for the list?, else > > Is the attribute defined in the site's global properties?, else > > attribute is undefined Indeed. My own email earlier this evening (UK time!) with its mention of "site-wide" users was itself a (known) over-simplification. (I was merely saying "a keen and selfish +1" for us being able to take advantage of any existing or imminent work, aligned with Mailman roadmaps, in this area.) Also high on our wish-list is true "virtual host" capability, and I can well see that we'd like some variety of how and where users are defined w.r.t. to this also. Some sort of inheritance scheme as you describe, which also includes the "virtual host" element would be good for us. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : From lcarlson at d.umn.edu Thu Jul 6 21:49:32 2006 From: lcarlson at d.umn.edu (Laura Carlson) Date: Thu, 06 Jul 2006 14:49:32 -0500 Subject: [Mailman-Developers] Accessible DOM manipulations In-Reply-To: References: Message-ID: <0AE959ACCEF1C4AED5CED12B@lcarslon.d.umn.edu> Ethan wrote: >>> One example is keeping extraneous text hidden until it is >>> selected; I imagine that someone using a screen reader/portable >>> device would appreciate being able to read a "overview" page >>> variant and then being able to expand as necessary. An overview at the top of a page is good usability. This is referred to as inverted pyramid [1]. The inverted pyramid is a type of writing style where conclusions are presented first not last. It begins with a conclusion then moves to the key information followed by background information. Usability studies show that web users want instant gratification. That is why the inverted pyramid style is important. Brad Knowles wrote: >> I would much prefer to do this without JavaScript. Because you can't >> guarantee that you know the way that page would be rendered if you >> send all sorts of "hidden" text that isn't shown until such time as >> someone does something to make it appear, and you can't control what >> kinds of mailicious cross-scripting attacks people may throw at you, >> it's best to simply not send anything that the user cannot currently >> see. Bryan Carbonnell wrote: > I have to agree with Brad on this. > > An option may be to give the site admin the ability to turn the JS > on/off site wide with a mm_cfg.py variable. Default set to off? For the non JS option maybe provide a table of contents or overview at the top of the page with plain old anchors to jump down to detailed information. Personally, I usually also dislike expandable/collapsible content is that relies on user action. But I haven't used Ethan's version yet. Hope it is keyboard friendly. BTW, some degree of accessibility checking for the app can be done simply by using keyboard techniques like tabbing (using no mouse). Blind users often browse web sites by tabbing from heading to heading or link to link. Keyboard techniques, such as tabbing through a page (tabbing through a page usually goes in the same order as a voice browser would read), is a good quick test. By tabbing you can check for any elements that cannot be accessed with the keyboard or that are in an illogical tabbing order. The first exercise I have my Web Accessibility class do is disable their browser. The the idea is to give them an idea as to what it's like to have access to the web restricted. It's goal is to help them to understand what it feels like, and hopefully get them thinking about how these problems can be overcome. These are their instructions: No, don't unplug the phone cord or Ethernet connection! Instead we are going to selectively disable certain features in your web browser. 1. Go into your preferences in your browser and turn off any and all of the following, if you can. (You may have to poke around a bit in "preferences" or internet settings, and not all browsers will allow you to disable everything. But the general intent is to turn off as much as you can.) - Images - Sound - Java - JavaScript - Style Sheets 2. Take your mouse/track ball/pointing device, unplug it, and throw it out the window. Okay, don't really do that, you might not be able to find it again. But don't use the mouse for the purpose of this exercise. 3. Look up the keyboard shortcuts for your browser in the help files or manual pages. Oops, I should have told you to do that before removing the mouse. Well, just remember that people with disabilities aren't magically born knowing how to run computers either, and if the help system is not accessible, they are in as much trouble as you are now! 4. With your "disabled" browsing system, look at five different web sites and attempt to use them. These should meet the following criteria: - They are sites you've used before. - They are sites where you can actually do something, and that something is of interest to you personally. - They are different types of sites (not all news, not all e-commerce, not all personal pages, etc). Look at a variety of sites. - Try to use these sites as you normally would, and record where you encountered any difficulties. What Was Your Experience Like? 1. What sites did you visit? 2. Were you able to perform your normal tasks? 3. What kind of obstacles, if any, did you encounter in accessing those sites? Best Regards, Laura [1] http://www.d.umn.edu/goto/usability#pyramid ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ From carbonnb at gmail.com Thu Jul 6 21:54:55 2006 From: carbonnb at gmail.com (Bryan Carbonnell) Date: Thu, 6 Jul 2006 15:54:55 -0400 Subject: [Mailman-Developers] Accessible DOM manipulations In-Reply-To: <0AE959ACCEF1C4AED5CED12B@lcarslon.d.umn.edu> References: <0AE959ACCEF1C4AED5CED12B@lcarslon.d.umn.edu> Message-ID: On 7/6/06, Laura Carlson wrote: > > An option may be to give the site admin the ability to turn the JS > > on/off site wide with a mm_cfg.py variable. > > Default set to off? That'd be my preference. -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From i at mindlace.net Thu Jul 6 22:45:26 2006 From: i at mindlace.net (emf) Date: Thu, 06 Jul 2006 16:45:26 -0400 Subject: [Mailman-Developers] Accessible DOM manipulations In-Reply-To: <33390.72.177.126.107.1152207509.squirrel@mail.his.com> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> Message-ID: <44AD7666.6000502@mindlace.net> Brad Knowles wrote: > I would much prefer to do this without JavaScript. Because you can't > guarantee that you know the way that page would be rendered Can you help me understand the basis for this claim? I have looked into the matter somewhat deeply and this works in every browser I have come across that supports JavaScript: document.getElementById('foo').style.display = 'none'; An intelligent layout allows you to minimize the amount of page rejiggering that goes on when you display text. Visual tests using Greasemonkey allow you to see all the visual states a page can get in (including different sized displays) to ensure you don't get into an unpleasant corner. Perhaps you mean to say that the variety of CSS implementations prevents me from knowing how a UA will render the page. Strictly speaking, this is true; pragmatically speaking, there exists suitable CSS that works in all current browsers that I know of. > if you send > all sorts of "hidden" text that isn't shown until such time as someone > does something to make it appear, The document with all the hidden text shown will be something like a "full detail" view; after all, I've promised the page will work fine with JavaScript off. > and you can't control what kinds of > mailicious cross-scripting attacks people may throw at you, I am unaware of any cross site scripting (XSS) attacks that can occur when a linked-in stylesheet uses the event model to alter the style of a element. Perhaps you are referring to the approach of using some mechanism (XMLHttpRequest or naive furl() type stuff) to fetch new bits to go into a page. This definitely a risk, and one I'm disinterested in playing with. I intend to use XMLHttpRequest to fetch JSON messages like "preferences saved" from the server. These messages will be carefully scrubbed and come only from server-generated translations, rendering them an improbable source of XSS. I also intend to use it for one-way communication where the client informs the server that something has changed via JSON. As with all form submissions, each JSON submission will have to come with the appropriate hashcash-esque validation element to be considered to come from the user. The UI benefit that drives the above choice is that I can provide the user with the UI state of the web app at the last time they used it, no matter what machine they come from. > it's best to simply not send anything that the user cannot currently see. I'm not sure I understand this principle. Most people have internet bandwidth that is inferior to the rendering speed of their browser, and a monitor that is smaller than most page content; some people (like those using screen readers) have essentially a 2d/linear monitor. This suggests that sending fewer, "larger" chunks is preferable to sending many smaller chunks when the user will be aware of the load time. The way modern rendering engines work makes 'hidden' text *much* faster to load during initial page rendering than it would if it were all displayed. One use case is where the new user clicks on all the help buttons to learn what's going on; a delay rendering help increases exploration cost. Another one is the way people read on the web. Nielsen [1] and many others in the usability field have shown that people scan, looking for key words, rather than reading. The fewer words the shorter the seek time and the more likely the user will do an exhaustive search of the page for what they're looking for. [1] http://www.useit.com/alertbox/9710a.html When it comes to screen readers, text *is* space; sighted individuals can skip big swaths of text with a single saccade, but a blind user must give voice to enough of the text to hear where they're going. This makes scanning text both temporally and cognitively more expensive than it is for sighted users. As screen readers *do* respect hidden/shown elements, I can significantly improve the user experience for them, while making life easier for visual uses as well. On somewhat of a side note, I have heard a certain amount of antipathy towards JavaScript in this forum. I know it was unpleasant in the late '90s, but it is much better and more cross-browser these days. I'm fairly certain that *some* author-initiated manipulation of a user's experience of a node set is obligatory in any conceivable Web; the only alternative I can see to using JavaScript or another interpreted language would be using something like XSLT, a horror that I shrink from even contemplating. ~ethan fremen From i at mindlace.net Thu Jul 6 22:51:00 2006 From: i at mindlace.net (emf) Date: Thu, 06 Jul 2006 16:51:00 -0400 Subject: [Mailman-Developers] Accessible DOM manipulations In-Reply-To: References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> Message-ID: <44AD77B4.8090707@mindlace.net> Bryan Carbonnell wrote: > I have to agree with Brad on this. > > An option may be to give the site admin the ability to turn the JS > on/off site wide with a mm_cfg.py variable. I'm a little reluctant to add another bit flip to mm_cfg when you'll be able to delete the .js files or forbid access to the js directory in apache and get what you want. Or you could avoid subjecting all your users to your preference and use the no-JS variant that will always be available, or just turn JS off in your browser. Can you help me understand your opposition to Javascript in a webpage you serve? Something specific rather than in principle, if you would be so kind; I often have a hard time applying abstract concepts to code I'm in the process of writing. Thanks for your help, ~ethan fremen From i at mindlace.net Thu Jul 6 23:47:21 2006 From: i at mindlace.net (emf) Date: Thu, 06 Jul 2006 17:47:21 -0400 Subject: [Mailman-Developers] Users, persistent storage, caches, etc. In-Reply-To: <1152210835.32574.191.camel@finch.boston.redhat.com> References: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> <44AD461A.1020902@mindlace.net> <1152210835.32574.191.camel@finch.boston.redhat.com> Message-ID: <44AD84E9.2000006@mindlace.net> John Dennis wrote: > Perhaps the right model is a hierarchical > resolution of attributes, e.g. In order to provide administrative control over what UI elements are implemented I'm already implementing a tool that will provide control over which elements are active on a Server/Site/List/User level. They're not strictly hierarchical; a User may wish to not see some controls for a particular list (e.g. mailman-checkins) that they want to see for others. Visibility is just one axis of state preferences, so I have to address this issue for more than just picking GUI bits ;) ~ethan fremen From i at mindlace.net Thu Jul 6 23:55:30 2006 From: i at mindlace.net (emf) Date: Thu, 06 Jul 2006 17:55:30 -0400 Subject: [Mailman-Developers] Parsing and Rendering rfc2822 In-Reply-To: <33408.72.177.126.107.1152207947.squirrel@mail.his.com> References: <44AAC503.9020901@mindlace.net> <1152111345.32574.18.camel@finch.boston.redhat.com> <44AC3F21.1020104@mindlace.net> <33408.72.177.126.107.1152207947.squirrel@mail.his.com> Message-ID: <44AD86D2.1090004@mindlace.net> Brad Knowles wrote: >>> Archiving and MLM (Mailing List Manager) functionality can be >>> orthogonal to each other. >> I can imagine - but have never used - a mailing list where access to >> past emails is 'orthogonal' to the use of the mailing list. > > Majordomo, older versions of Mailman, as just two examples of many. > > In fact, most MLMs don't necessarily have integrated archive components. I'm aware that many do not offer web interfaces to their archives. I know of none that doesn't provide access to their *archives*. Majordomo has offered an email way to get access to the archives for as long as I can recall, as does ezmlm, etc. One of the things that set Mailman apart in the early days was its web friendlyness and integration; this makes it even harder for me to see how the archive's web interface is separate from Mailman's UI. > And there are plenty of people who don't care for Pipermail and instead > integrate a third-party archive system into Mailman, in accordance with > the instructions that we provide in the FAQ Wizard. This doesn't strike me as evidence that an archive is orthogonal to the function of a mailing list; Rims are not orthogonal to the use of a car, yet many people replace them. > but we need to make sure we don't lose sight of these other archive systems I wholeheartedly agree. I don't think we currently have them in sight: we provide a way to turn off the existing archive system and offer to run popen() on the command of their choosing. The FAQ seems to suggest that we don't have it in sight as well: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.004.htp It seems to me that having an URL-accessable xml/rss/rdf/atom feed of the list would be much more "in sight" than the current state of affairs. > There are at least a couple of alternatives mentioned in the FAQ Wizard, > and John has clearly found at least one more. I have been looking around on this subject on and off for a few years. I have found a small number of OSS archiving programs: * MHonArc is in Perl and appears to be based on the RegExp Ninja school. * Lurker is in C++/XSLT. Neither presents an interface that appears substantially improved off of that provided by Pipermail from my perspective. The other projects I can find are abandoned. > But this is a pretty big undertaking. Well, it sounds like we're down to a "show me the code" sort of moment; I think with kid + python's built in email module I can whip something up that meets the low bar set by Pipermail within the allotted schedule. ~ethan fremen From i at mindlace.net Fri Jul 7 00:07:40 2006 From: i at mindlace.net (emf) Date: Thu, 06 Jul 2006 18:07:40 -0400 Subject: [Mailman-Developers] email schema / XSLT In-Reply-To: <1152211553.32574.202.camel@finch.boston.redhat.com> References: <44AAC503.9020901@mindlace.net> <1152111345.32574.18.camel@finch.boston.redhat.com> <44AC3F21.1020104@mindlace.net> <33408.72.177.126.107.1152207947.squirrel@mail.his.com> <1152209853.32574.175.camel@finch.boston.redhat.com> <1152211553.32574.202.camel@finch.boston.redhat.com> Message-ID: <44AD89AC.2000300@mindlace.net> John Dennis wrote: > Speaking of stylesheets and customized UI, are you planning on having > the core mailman code generate xml, which then is transformed with xslt? This would be nice. My immediate target is getting email into an ElementTree, and then displaying it using some combination of python and the xslt transforms available in kid. From an ElementTree, an XML representation is falling off a log; I will certainly make that available but clearly I might not have The One True Schema within the summer. > This might be more flexible than relying on javascript to control what > is presented to the user. When I used XSLT to handle formatting of a large xml file for display, I got into some painful pickles that could only be resolved by resorting to JavaScript. A trivial example: Get a unique list of elements from an XML file according to an attributes' presence or its value. Perhaps doable with a recent xslt engine on the server, but not in any browser I know of. Mostly it seems like going from rfc2822 -> ElementTree -> XML -> XSLT -> XHTML is more overhead than rfc2822 -> ElementTree/Kid -> output XML. The mbox is currently the canonical format; I don't intend to mess with tradition. > Sites can then replace the xslt if need be. They should be able to replace the kid templates if need be, or suck the straight XML representation and go to town. > Javascript still has a very valuable role to play and I'm not suggesting > not using it, but rather introducing an xslt transform means there would > be very little a site could not customize without ever touching mailman > internals. Hopefully this will still be true with the Kid templates. ~ethan fremen From jdennis at redhat.com Fri Jul 7 00:55:44 2006 From: jdennis at redhat.com (John Dennis) Date: Thu, 06 Jul 2006 18:55:44 -0400 Subject: [Mailman-Developers] email schema / XSLT In-Reply-To: <44AD89AC.2000300@mindlace.net> References: <44AAC503.9020901@mindlace.net> <1152111345.32574.18.camel@finch.boston.redhat.com> <44AC3F21.1020104@mindlace.net> <33408.72.177.126.107.1152207947.squirrel@mail.his.com> <1152209853.32574.175.camel@finch.boston.redhat.com> <1152211553.32574.202.camel@finch.boston.redhat.com> <44AD89AC.2000300@mindlace.net> Message-ID: <1152226544.32574.212.camel@finch.boston.redhat.com> On Thu, 2006-07-06 at 18:07 -0400, emf wrote: > John Dennis wrote: > > > Speaking of stylesheets and customized UI, are you planning on having > > the core mailman code generate xml, which then is transformed with xslt? > > This would be nice. My immediate target is getting email into an > ElementTree, and then displaying it using some combination of python and > the xslt transforms available in kid. Thanks for the thoughtful response Ethan. Actually I did a context switch on you without your knowing about it :-) I wasn't referring to just the email archiving, but rather all the pages mailman generates. I saw a subsequent post from you in which you said "xslt is evil" so I guess you're probably not too fond of this idea :-) I guess my thinking had been an xslt transform adds one more level of indirection that supports site customization in conjunction with css and javascript, albeit at the expense of additional complexity (the added cpu cycles can be mitigated by caching the transform result). Anyway, it was just an idea. -- John Dennis Red Hat Inc. From carbonnb at gmail.com Fri Jul 7 01:01:47 2006 From: carbonnb at gmail.com (Bryan Carbonnell) Date: Thu, 6 Jul 2006 19:01:47 -0400 Subject: [Mailman-Developers] Accessible DOM manipulations In-Reply-To: <44AD77B4.8090707@mindlace.net> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> Message-ID: On 7/6/06, emf wrote: > Bryan Carbonnell wrote: > > > I have to agree with Brad on this. > > > > An option may be to give the site admin the ability to turn the JS > > on/off site wide with a mm_cfg.py variable. > > I'm a little reluctant to add another bit flip to mm_cfg when you'll be > able to delete the .js files or forbid access to the js directory in > apache and get what you want. > > Or you could avoid subjecting all your users to your preference and use > the no-JS variant that will always be available, or just turn JS off in > your browser. > > Can you help me understand your opposition to Javascript in a webpage > you serve? Something specific rather than in principle, if you would be > so kind; I often have a hard time applying abstract concepts to code I'm > in the process of writing. Ethan, For me it's nothing specific. It's more philosophical. I am a very minimalist when it comes to the 'net. Plain text e-mail and no scripting or embeded audio/video on web pages. I think the content of the page should stand on its own legs and not rely on "fancy tricks" to make it appealing. I've seen WAY to much bad scripting (and I'm not implying that the code you are going to write is going to be bad) to actually want to implement and Javascript. I also know that quite a few of my users are going to be up in arms if scripting gets added to the pages. I just want to have the option to NOT use in in MM. I realize that I can just delete the JS file or disallow it with Apache, but I feel that since this is a MM endeavour I should be able to control it within MM and not have to resort to things like you mention to disable the JS. I know this sounds negative, it's not. I'm really glad the UI is getting overhauled. I have done what I could with the XHTML/CSS patch that I wrote, but I know the UI could be a LOT better. Just my $0.02 -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From barry at python.org Fri Jul 7 02:54:52 2006 From: barry at python.org (Barry Warsaw) Date: Thu, 6 Jul 2006 20:54:52 -0400 Subject: [Mailman-Developers] Accessible DOM manipulations In-Reply-To: <44AD7666.6000502@mindlace.net> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD7666.6000502@mindlace.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 6, 2006, at 4:45 PM, emf wrote: > On somewhat of a side note, I have heard a certain amount of antipathy > towards JavaScript in this forum. I know it was unpleasant in the late > '90s, but it is much better and more cross-browser these days. I'm sure a lot of that comes from me, inspired by early experience and my own general paranoid dinosaurism. OTOH, I remember Guido telling me a few years ago that I might as well give up on that one, and so I have -- mostly. That's why I love NoScript so much :). I'm no web developer expert by a long shot, but I've been following the discussions and istm that Ethan is striking a reasonable balance and is being extremely diligent in his research. I for one am quite eager to see what he comes up with! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK2w3HEjvBPtnXfVAQKNWgP+Okh3nAD4DmkvIA8FyvVw5z301gyEIiKS pzR2qKN3Rgl6uppBV0cvT09VQf9tVEFqnGOF2kw116tZ7CS8QjccAbend5mY0rlh grXIVahKR0EuLvjODronVPJ4fSPCd4oul5alZklXxmOJXyDTEtCmhUdwaeHsvM7P 1359VTu+YGA= =mjCZ -----END PGP SIGNATURE----- From barry at python.org Fri Jul 7 03:18:15 2006 From: barry at python.org (Barry Warsaw) Date: Thu, 6 Jul 2006 21:18:15 -0400 Subject: [Mailman-Developers] Users, persistent storage, caches, etc. In-Reply-To: <44AD461A.1020902@mindlace.net> References: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> <44AD461A.1020902@mindlace.net> Message-ID: <7357CB3F-1CBC-45BD-AE96-C56218CDA000@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 6, 2006, at 1:19 PM, emf wrote: > Barry et. al.: > > Barry, I've read about your SQLAlchemy work and look forward to seeing > that checkin ;) Heh, if only it worked. I've got a message sitting in my queue from their mailing list so I'm going to give it another go after I merge my locally committed other changes to the trunk (hopefully tonight). > 1.) I have to have a concept of user to really improve the user > interface. Many things become easier, but there are things I can do > with > a user-concept I can't do without it: > > a.) Different emails for different lists, same user. > b.) Providing moderator/admin privileges to a user rather than a > shared > secret. > > 2.) I need to store preference information somewheres. This includes: > site-wide UI configuration; list-wide UI configuration; user UI > preferences/state. > > 3.) I need to store caches somewhere; for some things it would be best > to keep them around, and maybe even in a more queryable format than > files. > > All of this leads me to- where should I stick things? Well, that's a good question, because the biggest feature of the mythical Mailman 3 is a unified user database. There simply isn't anything like that for Mailman 2. Each list, list archive, and member database is a silo and unwinding that is way too complicate to tackle for MM2. All the 'global' features currently visible in the options page are really hacks, requiring iteration through all mailing lists in order to imitate a global user database. To do it right requires hashing out a lot of issues, some of which have been discussed on the MM3 list or at sprints, but none of which are really functional. For example, should each domain on a server with virtual domains be a silo? (You'd need another level in point #2 above which represents the domain). Mailman really doesn't have a user-centric architecture and I think it's going to be difficult to wedge one in. It's worth discussing further though. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK22V3EjvBPtnXfVAQLpRAP+K5Ff7K0+5Mvwnc+Rcq7iVj9mtmjHs3kV /pOMzpWkWKKtt/JWlPXX6ml2n5ODXP6Nq/CRyYbwFl1xQyDCYiQ64WohJnJW4gQX 8dybLtWKlGTF4WPBd/Ey8uCGF/o4t2YZaiQC3C9wQql8rUMpd5JHCfYADxEAJtVC VyuE7lSyC0I= =IneM -----END PGP SIGNATURE----- From i at mindlace.net Fri Jul 7 03:49:40 2006 From: i at mindlace.net (emf) Date: Thu, 06 Jul 2006 21:49:40 -0400 Subject: [Mailman-Developers] email schema / XSLT In-Reply-To: <1152226544.32574.212.camel@finch.boston.redhat.com> References: <44AAC503.9020901@mindlace.net> <1152111345.32574.18.camel@finch.boston.redhat.com> <44AC3F21.1020104@mindlace.net> <33408.72.177.126.107.1152207947.squirrel@mail.his.com> <1152209853.32574.175.camel@finch.boston.redhat.com> <1152211553.32574.202.camel@finch.boston.redhat.com> <44AD89AC.2000300@mindlace.net> <1152226544.32574.212.camel@finch.boston.redhat.com> Message-ID: <44ADBDB4.5090803@mindlace.net> John Dennis wrote: > I wasn't referring to > just the email archiving, but rather all the pages mailman generates. Oh! well, they'll all be xhtml, so that should let you throw down some xslt action. > I saw a subsequent post from you in which you said "xslt is evil" so I > guess you're probably not too fond of this idea :-) Not quite Evil; I am quite fond of it, but I would say it's not a general-purpose programming language. The example I gave - get me a list of unique elements- is something like this in python: for element in nodeset: adict[element.name] = element while in XSLT it is the most brutally convoluted nonsense. anyway, kid will get us there with mucho less code; as kid kind of incorporates XSLT, I will still use it where appropriate. ~ethan fremen From bob at nleaudio.com Fri Jul 7 04:16:37 2006 From: bob at nleaudio.com (Bob Puff@NLE) Date: Thu, 06 Jul 2006 22:16:37 -0400 Subject: [Mailman-Developers] email schema / XSLT In-Reply-To: <1152226544.32574.212.camel@finch.boston.redhat.com> References: <44AAC503.9020901@mindlace.net> <1152111345.32574.18.camel@finch.boston.redhat.com> <44AC3F21.1020104@mindlace.net> <33408.72.177.126.107.1152207947.squirrel@mail.his.com> <1152209853.32574.175.camel@finch.boston.redhat.com> <1152211553.32574.202.camel@finch.boston.redhat.com> <44AD89AC.2000300@mindlace.net> <1152226544.32574.212.camel@finch.boston.redhat.com> Message-ID: <44ADC405.4040900@nleaudio.com> Some good discussion going on here regarding archives. Just thought I'd chime in on the pipermail thing. One thing that I find very disappointing is to (google|yahoo\fav search) a solution to a problem, only to find that the message that looks promising is in an archive that has been either nuked, moved, or reindexed, so you can no longer see the original message. Yes, Google's cache does help out a lot, but if you want to start reading the threads, it breaks quickly. If there was =any= way you could also include in your XML perhaps the original message id that the older pipermail created, you could then render those messages on the fly with the appropriate scripting, and even keep old URL links (perhaps under a 'legacy link' program or something). This brings up the next question: how are these messages to be stored? If its flat files, its gonna take a lot of processing if you have to render these on-the-fly. I do think that it is important to have a built-in archiving module. Pipermail is better than nothing. Bob From i at mindlace.net Fri Jul 7 05:05:46 2006 From: i at mindlace.net (emf) Date: Thu, 06 Jul 2006 23:05:46 -0400 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> Message-ID: <44ADCF8A.7080100@mindlace.net> Bryan Carbonnell wrote: > For me it's nothing specific. It's more philosophical. I am a very > minimalist when it comes to the 'net. Plain text e-mail and no > scripting or embeded audio/video on web pages. I can appreciate that philosophy, to some extent. So you always surf with JavaScript turned off? How do you turn off embedded media? Why is image embedding (I assume you don't turn off *all* images) acceptable within your philosophy while other media types are not? > I think the content of > the page should stand on its own legs and not rely on "fancy tricks" > to make it appealing. I agree that content should stand on its own legs. However, many websites- including mailman's interface - are applications where the *interaction* between the user and the content is at least as important as the content itself. I know of no application environment where the behaviour of an application's user interface can be specified entirely through declarative code. It's hard for me to see why one would want this in the first place; any dynamicism carries with it the requirement for some logical manipulation of the user interface and thus a requirement for logic. Things like XForms try to shove a good deal of this into a declarative syntax; I would happily code an interface in this fashion, but the vast and mysterious gods of the internet have not deemed it possible. If you even want to use a XSLT transformation in any dynamic way in browsers, you have to load it from JavaScript. You are, I assume, OK with the server doing whatever sort of dynamic foofaraw it likes to generate a given web page; what makes server side manipulations inherently superior to client-side manipulations? > I also know that quite a few of my users are going to be up in arms if > scripting gets added to the pages. Of any sort? No changing to a high-visibility stylesheet without refreshing the content (that hasn't changed?) No in-page form validation? No changing active and inactive form elements based on the user's prior selections? No showing users a rendered preview of text they enter? No autocomplete in any text element? No reordering a list without a zillion little checkboxes/number boxes and ambiguous behaviour if the same number is entered twice? No re-sorting of lists? No context-sensitive help beyond the title="" attribute? No user feedback of any sort until a Submit button is pressed? So in this philosophy, if I want to offer two mutually exclusive sets of options, I should: a.) display them both, then render a page saying "you can't do that" when they pick a combination that doesn't work; b.) make them resubmit the page with the appropriate radio button checked to see the 'other' possibility; c.) provide an additional bit of text that says "if you do x, then you can't do y"? What do you do when you have a data structure not well suited to tabular display or a list/tree? Just give the user fragments of the content? That's the part that gets me; if Content is sacrosanct, shouldn't providing as complete a picture in a given page's content be a goal? > I just want to have the option to > NOT use in in MM. I realize that I can just delete the JS file or > disallow it with Apache, but I feel that since this is a MM endeavour > I should be able to control it within MM and not have to resort to > things like you mention to disable the JS. I'm still not with you on this one; any user can turn off JS, but no user can turn on what you've disabled. ~ethan fremen From barry at python.org Fri Jul 7 05:21:02 2006 From: barry at python.org (Barry Warsaw) Date: Thu, 6 Jul 2006 23:21:02 -0400 Subject: [Mailman-Developers] What I did on my summer vacation In-Reply-To: <44AC2EC6.2050800@uni-paderborn.de> References: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> <44AC2EC6.2050800@uni-paderborn.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 5, 2006, at 5:27 PM, Arne Schwabe wrote: > Barry Warsaw schrieb: >> If you want to get a taste of the things I'm going to check in soon, >> please see: >> >> http://wiki.list.org/x/vg > > That page does not seem to public accessable. It asks me for a > username > / password. I think I've fixed this now. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK3TJHEjvBPtnXfVAQLeHgP8DAXhPxyWikf4U2+79vvNqb0+HfN8q1D+ 4gALanZHsiYfc+yGBB8srDi93U3iHQG17vnRfn0jpDEF8iEybrYiLsXLTOEBrH7D LEnIlL5p8PTfJr7RRu5WhHcsraHe8BFe2QaBgObVyX/PXX88vWXaTVSe66JtUbEq ctjd+Rf7jKc= =e2pj -----END PGP SIGNATURE----- From barry at python.org Fri Jul 7 05:26:17 2006 From: barry at python.org (Barry Warsaw) Date: Thu, 6 Jul 2006 23:26:17 -0400 Subject: [Mailman-Developers] Users, persistent storage, caches, etc. In-Reply-To: References: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> <44AD461A.1020902@mindlace.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 6, 2006, at 2:11 PM, David Lee wrote: > I've had to devise my own (very simple!) scheme for creating and > managing > a user database of email-address and password. (In our context, at > present, this could just about be managed by Mailman admin staff, > using a > command-line utility, but expansion to user-based self-maintenance, > and > via the WWW interface would be desirable.) > > So it sounds as if at least two of us (Ethan and me) are actively > looking > at implementing similar functionality (albeit initially for different > 'local' reasons). > > So a clear steer from the Mailman seers and soothsayers would be most > welcome so that Ethan's work and my work can aim in the same > direction as > anticipated Mailman 'futures'. > > Indeed, if the Mailman folk happen already to have a sketch of a > user-database scheme, that could be most useful to us... (Or > Ethan: I'd > be interested in tracking any work you do in this area!) One thing you definitely want to be sure to do is to add the appropriate API calls to MemberAdaptor.py, which is the official interface to all member-related data. You'll need an implementation as well, and that's where the user-centric architecture breaks down. However, it will soon be much easier to custom select a MemberAdaptor implementation, and in that case, you could conceivable write one that uses the OldStyleMemberAdaptor for all traditional user-related (list-centric) data, but then write a proxy or delegate that would store list-independent user data in a common place. Rough sketch: a directory sibling of 'lists' called 'domains' to hold domain-specific data, and then probably site-specific data in data/. But cascading options and all that stuff will probably have to wait until MM3. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK3UWXEjvBPtnXfVAQJI3AP7BJD/nn3hi96N8zrxkjovs/3ux6GWyCST XhMf2816eDwVLIn0B0Txw8F5WTFCNXdpyhGJxN4JqtVLeY4UDz6JFh0ktWpGPQml fiZ96GWAOnIH3rFwy1+dXrVmmFDKX5jbrDSC22Gk0SGkphTZ/2yXREbfD4RY69VW FhaDhDPt7uE= =XFTP -----END PGP SIGNATURE----- From brad at stop.mail-abuse.org Fri Jul 7 05:25:52 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 6 Jul 2006 23:25:52 -0400 (EDT) Subject: [Mailman-Developers] Accessible DOM manipulations In-Reply-To: References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD7666.6000502@mindlace.net> Message-ID: <37158.72.177.126.107.1152242752.squirrel@mail.his.com> Barry wrote: > I'm sure a lot of that comes from me, inspired by early experience > and my own general paranoid dinosaurism. OTOH, I remember Guido > telling me a few years ago that I might as well give up on that one, > and so I have -- mostly. That's why I love NoScript so much :). No, you're not the only one. I flat-out refuse to use most sites that require JavaScript, and run with JavaScript, Java, popups, and most extensions turned off by default (especially Flash). With Safari, I use PithHelmet to control what few sites I encounter that I will allow to use JavaScript, Java, plug-ins, etc... and when I'm running Firefox I use NoScript plus a number of other similar tools to do the same. Unfortunately, most of the sites which try to force me to use JavaScript do such a horrible job that they're pretty much completely unusable on MacOS X regardless of whether I use Safari or Firefox (or Opera, or anything else), and whether or not I allow JavaScript or not. I've been burned badly and repeatedly. And new sites are always popping up all over the place that continue to introduce me to new ways to screw up my browser and my machine, primarily through JavaScript, Flash, and all that other crap that I always leave turned off. You'll drag me into a pure JavaScript/AJAX world over my dead body -- and maybe a few million dead web site authors, if I can ever get my hands on the football. > I'm no web developer expert by a long shot, but I've been following > the discussions and istm that Ethan is striking a reasonable balance > and is being extremely diligent in his research. I for one am quite > eager to see what he comes up with! I'm skeptical, but I am curious to see the result. I hope I'm being open-minded enough that I'm giving him a fair chance to convince me that these kinds of things are not Inherently Evil. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From barry at python.org Fri Jul 7 05:29:38 2006 From: barry at python.org (Barry Warsaw) Date: Thu, 6 Jul 2006 23:29:38 -0400 Subject: [Mailman-Developers] Users, persistent storage, caches, etc. In-Reply-To: <1152210835.32574.191.camel@finch.boston.redhat.com> References: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> <44AD461A.1020902@mindlace.net> <1152210835.32574.191.camel@finch.boston.redhat.com> Message-ID: <59525B90-0467-4B4D-A963-46EB92B414CC@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 6, 2006, at 2:33 PM, John Dennis wrote: > My apologies, I have yet to read Barry's SQL work so perhaps the issue > of how a user is defined has been greatly enhanced over the current > 2.1 > model. It hasn't and frankly I don't see that as a possibility in the MM2.2 time frame. Not to discourage experimentation by Ethan, David and others, but it will necessarily be a hybrid solution until MM3. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK3VInEjvBPtnXfVAQLhIQQAsduzaxssD96jbrBjgtz/DNWWF/Zv2MLI Z3c/FOqY7P4PXQ9+yFo3iIruVo7oe+HVEX8dymgmI5IzqKQCvv2d1Groel25Zko6 GFpZNKhkqOhGw1DE1BeeFTaPYUDhwPYopB7XNj1Zg5Twzwu3A3AK/HNuE0MMtrVM EqR30Dv0lqU= =QIYx -----END PGP SIGNATURE----- From barry at python.org Fri Jul 7 05:48:48 2006 From: barry at python.org (Barry Warsaw) Date: Thu, 6 Jul 2006 23:48:48 -0400 Subject: [Mailman-Developers] John Dennis Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry to go on-list about this but I can't reply to John Dennis; Redhat's mail server is blocking me. John if you have an alternative email address, contact me off-list and I'll forward you the rejection message. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK3ZoHEjvBPtnXfVAQKjFQP6AmwsRjpnbwhvPoJ6vghhDzdUXQ5UQc/i 4jjuWJJmnv3LBWu4AJy8jNilQSMTedniFKXfwqPukAjylPth1TFexC/V1rOvOWus Gr/zayl7hnJVBMk+USdRCogKmOLB1//VcbCfaYgAQYTsc9gQNm7ssbSEaNawsz5t t6JTRBv2L+0= =yOS4 -----END PGP SIGNATURE----- From barry at python.org Fri Jul 7 06:00:58 2006 From: barry at python.org (Barry Warsaw) Date: Fri, 7 Jul 2006 00:00:58 -0400 Subject: [Mailman-Developers] email schemas In-Reply-To: <44AD4887.9050209@mindlace.net> References: <44AAC503.9020901@mindlace.net> <5F9167F185C38011D2066E27@lewes.staff.uscs.susx.ac.uk> <44AD245D.3020804@mindlace.net> <1152199808.32574.88.camel@finch.boston.redhat.com> <87438C7E29D9D8A15525A228@lewes.staff.uscs.susx.ac.uk> <1152205840.32574.137.camel@finch.boston.redhat.com> <44AD4887.9050209@mindlace.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 6, 2006, at 1:29 PM, emf wrote: > Another approach would be something like: > >
To bob at dobbs.org
> ... >
X-Foo blarg
> > I'm not against that. It might sense to use RFC 2822 terminology: Tosomeone at example.com ... ??? I think you do probably want to give additional structure to the , mirroring the message's multipart structure. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK3cenEjvBPtnXfVAQJ7/wP+IUX/ONANJ5xlYHg5nioRNVYbzc/uWswt 2PnSj/nNGQj11PvD9xCo4uem9A1BWHRq1fzT/BUrQXDGvhU1ajr9TIh/RzKjAjI8 jE0D3w0VeHNNcOVwIoX94uBc/ZyajgyZHlCO2NmoRm1lYlz+VOKK3DtDore5AKeo MAwB5+wQvKM= =0AS6 -----END PGP SIGNATURE----- From barry at python.org Fri Jul 7 06:02:07 2006 From: barry at python.org (Barry Warsaw) Date: Fri, 7 Jul 2006 00:02:07 -0400 Subject: [Mailman-Developers] Parsing and Rendering rfc8222 In-Reply-To: <33514.72.177.126.107.1152208601.squirrel@mail.his.com> References: <44AAC503.9020901@mindlace.net> <34837.72.177.126.107.1152048804.squirrel@mail.his.com> <0163A9DF-2CEB-48BE-B301-B9F760E14A50@python.org> <33514.72.177.126.107.1152208601.squirrel@mail.his.com> Message-ID: <6D5A4C49-8829-41E6-9267-E656E5D3D8C3@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 6, 2006, at 1:56 PM, Brad Knowles wrote: > Barry said: > >> We should certainly do everything we can to make sure that Richard's >> ht:dig solution is nearly trivial to integrate, but I'm not sure we >> should distribute it with Mailman. > > Sorry, I guess I wasn't clear -- I just meant for him to look at both > Python and non-Python solutions, before deciding what was going to > be done > and how. > > I wasn't advocating the incorporation of ht:dig itself into the > stuff we > ship. At least, I didn't mean for it to come off that way. Cool, +1 - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK3cv3EjvBPtnXfVAQJd9AQAnhPFHyIpMyVyzeRzQ8Xn3ZZNcmeRW+T9 HHE162EMEskuXEaZ4FzorpZ/6bAVp1IUqZ9oArEimF/CU6jRolcMyCct0n/Va0RS cJMybtddQlq6g7OMvlH1RCQBMn4uMaBvhtQOcqQQlCoLq5G2Pdcvrvvz+6rwjfUk fWDDnuCJc38= =Ypl5 -----END PGP SIGNATURE----- From barry at python.org Fri Jul 7 06:04:57 2006 From: barry at python.org (Barry Warsaw) Date: Fri, 7 Jul 2006 00:04:57 -0400 Subject: [Mailman-Developers] email schemas In-Reply-To: <1152209358.32574.168.camel@finch.boston.redhat.com> References: <44AAC503.9020901@mindlace.net> <5F9167F185C38011D2066E27@lewes.staff.uscs.susx.ac.uk> <44AD245D.3020804@mindlace.net> <1152199808.32574.88.camel@finch.boston.redhat.com> <87438C7E29D9D8A15525A228@lewes.staff.uscs.susx.ac.uk> <1152205840.32574.137.camel@finch.boston.redhat.com> <44AD4887.9050209@mindlace.net> <1152209358.32574.168.camel@finch.boston.redhat.com> Message-ID: <735A9F52-5C78-4166-B759-2CE20DE9354B@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 6, 2006, at 2:09 PM, John Dennis wrote: >> As I understand it, any user agent is free to throw on any X-header >> their little heart desires, so that strikes me as a lack of a-priori >> knowledge. > > No problem, silently ignore unknown fields. I don't think you'll want to do that. There's lots of good meat in them thar X- headers! > Since you'll going to have to deal with unknown names I think I would > prefer both well known names and unknown extended names have identical > document structure rather than special casing the extended names in an > independent way. Special casing during a document traversal based on > context introduces unnecessary pain. I'm not sure I agree. The structural parts of the message are header, field name, field value, etc. "To", "From", "Subject" and such feels like content to me. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK3daXEjvBPtnXfVAQJn8QP+JdPxwCM5oyrlTkNL5YgqCf+s2qYEHQNh Uf5+RwTXRibZ7t0Y7d+F9fW5tSwx9hxElcKzTYs8rvX+JEyx4f8GRfcmrtVKfBOU vxBTE4BtzqDxG+GkZNjoJls9BGrg+zS6e4xD+Nra41NHcrmIIfFnbRhFJVFOA6v4 6qlPJPrktGM= =rAUD -----END PGP SIGNATURE----- From brad at stop.mail-abuse.org Fri Jul 7 06:08:54 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri, 7 Jul 2006 00:08:54 -0400 (EDT) Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: <44ADCF8A.7080100@mindlace.net> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> Message-ID: <37460.72.177.126.107.1152245334.squirrel@mail.his.com> Ethan quoted Bryan Carbonnell: >> For me it's nothing specific. It's more philosophical. I am a very >> minimalist when it comes to the 'net. Plain text e-mail and no >> scripting or embeded audio/video on web pages. > > I can appreciate that philosophy, to some extent. So you always surf > with JavaScript turned off? How do you turn off embedded media? Why is > image embedding (I assume you don't turn off *all* images) acceptable > within your philosophy while other media types are not? When I browse, I don't turn off GIF, JPEG, or PNG images, although I do wish I could turn off GIFs (they are/were encumbered by patents and I don't support any kind of software patent, and are also a security risk). Since these things are rendered from within the browser itself, short of turning off all images, I don't think I have a choice. But I do browse with multimedia and flash turned off by default, except for those few sites that I've decided to take a risk on. > I agree that content should stand on its own legs. However, many > websites- including mailman's interface - are applications where the > *interaction* between the user and the content is at least as important > as the content itself. One thing that really concerns me is excessive complexity in the user interface. As a MacOS X/Safari user, I've found so damn bloody many web sites that are totally hosed for me, regardless of whether I allow them to use JavaScript or not. Virtually every single web page designer I've ever met has always had Windows/Internet Explorer on the brain, and they don't care about anything else. In fact, I honestly believe that many of them actively work to break their websites on all other types of browsers and platforms, just so that they can force you to use Windows and Internet Explorer. Being sensitive to this sort of thing in my own condition, I really don't want to see us creating a similar situation for someone else. Now, I know that you're not that kind of person, and you will actively test your work with MacOS X/Safari, and as many other browser/OS platforms you can. But the more complexity that is built into the user interface, the higher the likelihood is that something will accidentally happen somewhere to seriously break something for someone else. In fact, I think it's quite likely that you will even be put into a situation where a bug in a given platform/browser combination causes you to completely re-work a lot of your carefully written code, or even completely abandon the idea of providing certain features that you had once thought very important. So, my vote is to set expectations a lot lower, prove to yourself (and us ;-) that you really can implement that restricted set of features on all specified platform/browser combinations, and then hopefully you will have produced a set of specifications and a design that is easily adaptable for future work to expand on those options and provide more of the kinds of advanced features that you were looking for. In other words, I'd like to see that you really can walk in all the different likely shoe and surface combinations, before we let you draft us into supporting your plans to win the marathon -- especially if we're all going to be giving you all our scissors, razors, knives, swords, and other bladed instruments. > You are, I assume, OK with the server doing whatever sort of dynamic > foofaraw it likes to generate a given web page; what makes server side > manipulations inherently superior to client-side manipulations? Pretty much, yes. So long as it comes across the wire to my browser as pretty plain-jane HTML, I don't really care too much what you do on the back-end. At least there, you've got a much more restricted set of platform/server combinations that you have to worry about, and hopefully Python can help you hide a lot of those complexities. > No in-page form > validation? I'd rather not, no. I have yet to see a single place on the Internet that actually does it right, and across all platform/browser combinations. More often than not, when typing in a phone number, I'll be unable to enter the last four digits because they simply set a length limitation on the field, and didn't bother to check for non-numeric characters. Or, when I was living in Belgium, my phone number had to be much longer than anyone in the US is used to, because it had to include some sort of indication that I was providing an international phone number, plus my country code, and all the other local stuff. > No showing users a rendered preview of text > they enter? I'd rather not, no. Again, every single website I've ever seen that tries to show me exactly what my comment is going to look like ends up not working very well. When it's not flat-out broken, it's slow and distracting. I'd rather focus on the words and not whether I've got the right fiddly font or the right fiddly kerning, or whatever. > No autocomplete in any text element? No, my browser is annoying enough when it tries to do autocomplete, and it almost always fails to autocomplete what I'm trying to type in the way I would want it to. > No reordering a list > without a zillion little checkboxes/number boxes and ambiguous behaviour > if the same number is entered twice? Not really, no. When I've seen that done in the past, it was almost always dead-dog slow and far more of an annoyance than any help that it could possibly have been. Like that damn bloody stupid "find as you type" crap. I've learned a few things about torture over the years. I'd like to test them all on the guy who invented that idea, and then maybe see if I can come up with a few more new concepts in that area that have never previously been explored. And there's no way I'd let that guy pull a Ken Lay and up and die on me before I'm done with my experiments. > What do you do when you have a data structure not well suited to tabular > display or a list/tree? Just give the user fragments of the content? I'm not sure that I've got any answers for you, with regards to how you should resolve this issue. I'm just telling you the sorts of things I have had experience with in the past, and which I would be very annoyed to ever have to encounter again at any time in the future. > That's the part that gets me; if Content is sacrosanct, shouldn't > providing as complete a picture in a given page's content be a goal? Yes, but it's not physically possible to test with all possible platform/browser combinations that will exist throughout all of history (at least, throughout the entire history of the program you're designing), and it's not physically possible to know, a priori, everything that any user might ever want to do under any and all possible circumstances. Some things you can guess at, and provide reasonable failure modes should you guess wrong. Other things you can guess at, but the failure modes are going to be quite a bit more nasty. And then there are a lot of things that you would never have guessed in a million years, and you've got to wonder what complex code is going to do under those circumstances and what the failure modes will be. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From barry at python.org Fri Jul 7 06:12:51 2006 From: barry at python.org (Barry Warsaw) Date: Fri, 7 Jul 2006 00:12:51 -0400 Subject: [Mailman-Developers] email schema / XSLT In-Reply-To: <44ADC405.4040900@nleaudio.com> References: <44AAC503.9020901@mindlace.net> <1152111345.32574.18.camel@finch.boston.redhat.com> <44AC3F21.1020104@mindlace.net> <33408.72.177.126.107.1152207947.squirrel@mail.his.com> <1152209853.32574.175.camel@finch.boston.redhat.com> <1152211553.32574.202.camel@finch.boston.redhat.com> <44AD89AC.2000300@mindlace.net> <1152226544.32574.212.camel@finch.boston.redhat.com> <44ADC405.4040900@nleaudio.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 6, 2006, at 10:16 PM, Bob Puff at NLE wrote: > One thing that I find very disappointing is to (google|yahoo\fav > search) a solution to a problem, > only to find that the message that looks promising is in an archive > that has been either nuked, > moved, or reindexed, so you can no longer see the original > message. Yes, Google's cache does help > out a lot, but if you want to start reading the threads, it breaks > quickly. I agree. Sadly, Pipermail's original message id algorithm (and the one we still use) is extremely fragile, and in fact, due to archiving bugs in the past, if you were to regen your archive even now, you'd probably break links. > If there was =any= way you could also include in your XML perhaps > the original message id that the > older pipermail created, you could then render those messages on > the fly with the appropriate > scripting, and even keep old URL links (perhaps under a 'legacy > link' program or something). I think it's a great idea. Have to think about how/if that's even possible. > This brings up the next question: how are these messages to be > stored? If its flat files, its gonna > take a lot of processing if you have to render these on-the-fly. I'm sure you'll want to cache the pages, with ways to chuck the cache at various times (e.g. globally when the email obfuscation algorithm is modified for a site). - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK3fQ3EjvBPtnXfVAQJIGQP+MxXjiRSPgNRyzEYb6OfZB5jKBM4Cyht+ Ozymw/qoZeQ0qop2BTkywYmiqKY/Sq0k9cBlDSt8SJJ2ULzVw9WKABCjyZpAjghw FSWRdrX/ElMpEiQibjAPo9vH0fujybhZX0tJhygZTEt+RSeL9l9IC+acH+tKf2VA UnYUEMk6rmo= =UR+F -----END PGP SIGNATURE----- From barry at python.org Fri Jul 7 06:33:28 2006 From: barry at python.org (Barry Warsaw) Date: Fri, 7 Jul 2006 00:33:28 -0400 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: <37460.72.177.126.107.1152245334.squirrel@mail.his.com> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> <37460.72.177.126.107.1152245334.squirrel@mail.his.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 7, 2006, at 12:08 AM, Brad Knowles wrote: > One thing that really concerns me is excessive complexity in the user > interface. As a MacOS X/Safari user, I've found so damn bloody > many web > sites that are totally hosed for me, regardless of whether I allow > them to > use JavaScript or not. Virtually every single web page designer > I've ever > met has always had Windows/Internet Explorer on the brain, and they > don't > care about anything else. In fact, I honestly believe that many of > them > actively work to break their websites on all other types of > browsers and > platforms, just so that they can force you to use Windows and Internet > Explorer. OTOH, I've used Linux and OSX, and before that NeXT, Solaris and various Unixes for (unfortunately, way :) longer than there's been a web, and except for the Windows programming I do at work, haven't ever used IE for any substantial amount of time. I'm not excusing poor sites or Windows-specific sites, but for the most part, these days most sites are at least usable with Firefox on various platforms. (The one sole recent exception was the SQLAlchemy doc pages which gave Firefox fits but rendered just fine in Safari -- and I'm sure those guys didn't tailor their pages for IE.). Yeah, you hit the occasional WMV or ActiveX laden site, but I'm much more bugged by the Flash-only sites that are an avoidable annoyance for me, but I can imagine are a scream-out-loud frustration for screen reader based users. > Now, I know that you're not that kind of person, and you will actively > test your work with MacOS X/Safari, and as many other browser/OS > platforms > you can. But the more complexity that is built into the user > interface, > the higher the likelihood is that something will accidentally happen > somewhere to seriously break something for someone else. Actually, I think skilled and judicious use of modern web technology can help to /reduce/ the complexity of Mailman's interface. Something I constantly struggle with is the plethora of configuration variables (both via the web u/i and in mm_cfg.py) that makes the system highly complicated. I would love to have a self-discoverable interface, or an interface that can be used to selectively reveal just the parts you're interested. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK3kGXEjvBPtnXfVAQJfrQQAoYkRLIATvJrLsM2kx88DF4UZHbeoXXZI CrIhzM2URy+IIcRMQCBn8jfqnyIeTvVUcemHiCjpDyhyVEuYlYXtvjT9d5W9DrjR OW3rlDViFfuEA6NSU+/QS8YDhokpf2tLpbdKiKLdqgiAdMGR8+jhHFEsmbsha79d xX7xKMzNmOY= =/Mp9 -----END PGP SIGNATURE----- From msapiro at value.net Fri Jul 7 06:50:12 2006 From: msapiro at value.net (Mark Sapiro) Date: Thu, 6 Jul 2006 21:50:12 -0700 Subject: [Mailman-Developers] sender-based authentication In-Reply-To: Message-ID: David Lee wrote: > >Being completely new to both Mailman and python programming (though with >several years of majordomo and perl behind me!) I thought I'd check that >I'm on the right lines. Attached is a shot at a "UserAuth.py" module(?) >to maintain the passwords, with ideas borrowed from "Utils.py". > >Does it seem the right sort of thing? Does it conform to the spirit of >Mailman? Or is it hopelessly wrong or idiosyncrantic? It seems to me to be the right sort of thing, but I see some specific issues. 1) It might be better to use anydbm rather than dbm. Some Python installations might have dbhash and/or gdbm available and not dbm. 2) I'm not sure why you want to give default values of None to missing arguments when the arguments are really required and the default None values throw exceptions anyway. 3) The database file can be left open, either because of your explicit exceptions or because of exceptions due to 2). E.g., def add(user=None, password=None): oldmask = os.umask(026) try: file = dbm.open(filename, 'c') if file.has_key(user): raise KeyError file[user] = sha.new(password).hexdigest() file.close() finally: os.umask(oldmask) If I call add(), then I get some exception (which depends on the particular dbm module) and file is not closed (until garbage collected which may not happen immediately). A subsequent call to add('user_name', 'user_pwd') may fail with a permission error on the open (again depending on the particular dbm module). It would be better to move file.close() into the finally clause, perhaps within its own try so it doesn't skip the resetting of umask if the open failed. 4) PEP 8 recommends all lower case module names, although consistency with existing Mailman module names probably overrides that. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at python.org Fri Jul 7 06:55:27 2006 From: barry at python.org (Barry Warsaw) Date: Fri, 7 Jul 2006 00:55:27 -0400 Subject: [Mailman-Developers] sender-based authentication In-Reply-To: References: Message-ID: <000A4208-56EE-44FB-ADF0-31E9C9898003@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 7, 2006, at 12:50 AM, Mark Sapiro wrote: > 4) PEP 8 recommends all lower case module names, although consistency > with existing Mailman module names probably overrides that. I haven't had time to look at the patch yet, but I've been trying to be more aligned with PEP 8 in all new code, and at some point I'd like to do a Grand Renaming (or er, grandrenaming) of the existing modules (although some provision will have to be made for pickled class names like Mailman.Message.Message). So for new code, please use PEP 8 module names. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK3pP3EjvBPtnXfVAQJCfAQArCmIYuu4UnFLojc8BHK0T/SSUSrj2ls0 63G4I17pjU7hKr5AlWnKvLTypQW37avPd/Snt9hrp2eFVLUoy1k2m6861cVVAfo6 D3fShbqRots/aGtCarQgvOQpHIMiTbaeajlItPX8FuPuujNtPPEODqJZq3ssz+Nm NBeZHJPxyK8= =eV92 -----END PGP SIGNATURE----- From brad at stop.mail-abuse.org Fri Jul 7 06:58:33 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri, 7 Jul 2006 00:58:33 -0400 (EDT) Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> <37460.72.177.126.107.1152245334.squirrel@mail.his.com> Message-ID: <38818.72.177.126.107.1152248313.squirrel@mail.his.com> Barry wrote: > OTOH, I've used Linux and OSX, and before that NeXT, Solaris and > various Unixes for (unfortunately, way :) longer than there's been a > web, and except for the Windows programming I do at work, haven't > ever used IE for any substantial amount of time. I've been using Unix and the Internet since the summer of 1984, and a Macintosh Fanatic since December of 1983 (when I saw a prototype, before the official unveiling during the SuperBowl commercial). I've never voluntarily used IE, except when I'm at my parents house and I need to do something on the web with her computer -- which is almost never, since I always take my laptop with me. > I would love to have a self-discoverable > interface, or an interface that can be used to selectively reveal > just the parts you're interested. I just read the intro to a Slashdot article at , which quoted the following section: | Dollar for dollar, network-based computers are faster. Unless you're playing Grand Theft | Auto or watching HDTV, your network isn't the slowest part of your setup. It's the | consumer-grade Pentium and disk drive on your Dell, and the wimpy home data bus | that connects them. Home computers are marketed with slogans like "Ultimate | Performance," but the truth is they're engineered to run cool, quiet, and slow compared | to commercial servers. I'm not 100% certain the original author being quoted by Slashdot is right, but at the very least I think you have to give some serious consideration to what the author is saying. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From i at mindlace.net Fri Jul 7 07:34:01 2006 From: i at mindlace.net (emf) Date: Fri, 07 Jul 2006 01:34:01 -0400 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: <37460.72.177.126.107.1152245334.squirrel@mail.his.com> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> <37460.72.177.126.107.1152245334.squirrel@mail.his.com> Message-ID: <44ADF249.30606@mindlace.net> Brad Knowles wrote: > One thing that really concerns me is excessive complexity in the user > interface. As a MacOS X/Safari user, I've found so damn bloody many web > sites that are totally hosed for me, regardless of whether I allow them to > use JavaScript or not. I can see that; I have that problem intermittently. > But the more complexity that is built into the user interface, > the higher the likelihood is that something will accidentally happen > somewhere to seriously break something for someone else. This is really vague; I have no idea how, given that I have said that this thing will work without JavaScript on at all, this "don't do it because it might be complicated" heuristic is applicable. > In fact, I think it's quite likely that you will even be put into a > situation where a bug in a given platform/browser combination causes you > to completely re-work a lot of your carefully written code, I'll put $10 down on the side of "I know what browsers do" and thus won't have to re-work my code to accommodate one broken browser. > In other words, I'd like to see that you really can walk in all the > different likely shoe and surface combinations, before we let you draft us > into supporting your plans to win the marathon -- especially if we're all > going to be giving you all our scissors, razors, knives, swords, and other > bladed instruments. This strikes me as an argument from extremes; I am not advocating doing anything particularly complex. > I'd rather not, no. I have yet to see a single place on the Internet that > actually does it right, and across all platform/browser combinations. If you would give a concrete example maybe we could get past FUD. > More often than not, when typing in a phone number, I'll be unable to > enter the last four digits because they simply set a length limitation on > the field, and didn't bother to check for non-numeric characters. Length limitation is something you can set in HTML. It's possible to make that mistake in JavaScript, too, but it's not JavaScript's fault. > I'd rather not, no. Again, every single website I've ever seen that tries > to show me exactly what my comment is going to look like ends up not > working very well. Have you used http://wiki.list.org/ ? Is it "flat out broken" or "slow and distracting"? I find it has a few bugs, but mostly it works well. >> reordering a list without a zillion little checkboxes/number boxes and ambiguous behaviour >> if the same number is entered twice? > > Not really, no. When I've seen that done in the past, it was almost > always dead-dog slow and far more of an annoyance than any help that it > could possibly have been. Here's a specific example that works well for me: Does the drag/drop of boxes on the customized google home page not work for you? You don't have to sign in to try it, and it allows drag/drop reordering for me in Safari just fine, and way more intuitively than resubmitting the page after clicking on buttons. > Like that damn bloody stupid "find as you type" crap. I've learned a few > things about torture over the years. I'm sorry that this has been so unpleasant for you. I find it helpful in several cases. >> What do you do when you have a data structure not well suited to tabular >> display or a list/tree? Just give the user fragments of the content? > > I'm not sure that I've got any answers for you, with regards to how you > should resolve this issue. So you have no constructive feedback, nor a sufficiently detailed critique that I can even address your concerns. I'm not sure what you would have me do with your advice, beyond my already existing commitment to make the page work without JavaScript. > it's not physically possible to know, a priori, everything that any > user might ever want to do under any and all possible circumstances. If this were the criteria, no user interface would ever get built. I have already articulated a strategy that covers all browsers currently released with a measurable market share. * IE 5+, Mozilla (any), Safari from 1.0+ and any other KHTML browsers, JAWS 6+, Opera 6+, Lynx, Links. All in any combination of Images/CSS/JavaScript off/on. I look forward to your feedback when I have something that you can try; perhaps that will help us talk about specific issues. ~ethan fremen From i at mindlace.net Fri Jul 7 07:55:50 2006 From: i at mindlace.net (emf) Date: Fri, 07 Jul 2006 01:55:50 -0400 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: <38818.72.177.126.107.1152248313.squirrel@mail.his.com> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> <37460.72.177.126.107.1152245334.squirrel@mail.his.com> <38818.72.177.126.107.1152248313.squirrel@mail.his.com> Message-ID: <44ADF766.1090101@mindlace.net> Brad Knowles wrote: > I just read the intro to a Slashdot article at > , which quoted the > following section: > > | Dollar for dollar, network-based computers are faster. This is incorrect, based on my experience of working in a few data centers. While it is possible to buy expensive hardware today that has more performance than the average consumer machine, hardware is getting better faster than purchasing decisions. Because the consumer market is both larger and growing faster than the server market, and the machines less reliable, the average server is older than the average client machine, and thus have less resources than the average client. Even if you disagree with this point, there's one server for many clients; the amount of resources available to devote to the task of an individual user's web experience is almost always greater on their end of the pipe. What it boils down to is that people perceive change at around 150msec; very few net users get anywhere near this latency, and so for most, the round-trip delay represents a substantial impediment to the responsiveness of the interface. ~ethan fremen From i at mindlace.net Fri Jul 7 08:01:19 2006 From: i at mindlace.net (emf) Date: Fri, 07 Jul 2006 02:01:19 -0400 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: <37460.72.177.126.107.1152245334.squirrel@mail.his.com> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> <37460.72.177.126.107.1152245334.squirrel@mail.his.com> Message-ID: <44ADF8AF.8070201@mindlace.net> Brad Knowles wrote: >> No reordering a list >> without a zillion little checkboxes/number boxes and ambiguous behaviour >> if the same number is entered twice? > > Not really, no. When I've seen that done in the past, it was almost > always dead-dog slow and far more of an annoyance than any help that it > could possibly have been. Can you do me a favor and let me know how these examples work for you? http://tool-man.org/examples/sorting.html ~ethan fremen From t.d.lee at durham.ac.uk Fri Jul 7 11:39:09 2006 From: t.d.lee at durham.ac.uk (David Lee) Date: Fri, 7 Jul 2006 10:39:09 +0100 (BST) Subject: [Mailman-Developers] Users, persistent storage, caches, etc. In-Reply-To: <59525B90-0467-4B4D-A963-46EB92B414CC@python.org> References: <2947B176-9585-4D1D-99CC-BD11F32823D0@python.org> <44AD461A.1020902@mindlace.net> <1152210835.32574.191.camel@finch.boston.redhat.com> <59525B90-0467-4B4D-A963-46EB92B414CC@python.org> Message-ID: On Thu, 6 Jul 2006, Barry Warsaw wrote: > On Jul 6, 2006, at 2:33 PM, John Dennis wrote: > > > My apologies, I have yet to read Barry's SQL work so perhaps the issue > > of how a user is defined has been greatly enhanced over the current > > 2.1 > > model. > > It hasn't and frankly I don't see that as a possibility in the MM2.2 > time frame. Not to discourage experimentation by Ethan, David and > others, but it will necessarily be a hybrid solution until MM3. That's an OK answer for me, because it gives a realistic view of what the next couple of years hold, and indicates that fully solving the user-database issue is a major task. Thanks. So because of our local need for a simple sender-based authentication scheme, I should probably aim for something small, easy and local simply to get us through the next year or two, while fully aware that we might have to do a (possibly significant) transition job further down the road. Thanks. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : From iane at sussex.ac.uk Fri Jul 7 12:13:17 2006 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 07 Jul 2006 11:13:17 +0100 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: <44ADCF8A.7080100@mindlace.net> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> Message-ID: --On 6 July 2006 23:05:46 -0400 emf wrote: > You are, I assume, OK with the server doing whatever sort of dynamic > foofaraw it likes to generate a given web page; what makes server side > manipulations inherently superior to client-side manipulations? It's simple. You know what you can do on the server, you don't know what you can do in the client. The site has to be able to work without client side scripting, so it would be useful to disable it in Mailman. One reason we might choose to switch off client side scripting is so that we can support our 20,000 odd users without having to worry about which view of Mailman they're seeing. We'll probably resist that, but our front line support would probably prefer a single interface for everyone - and that would necessarily be the java free interface. -- Ian Eiloart IT Services, University of Sussex From iane at sussex.ac.uk Fri Jul 7 12:14:44 2006 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 07 Jul 2006 11:14:44 +0100 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: <37460.72.177.126.107.1152245334.squirrel@mail.his.com> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> <37460.72.177.126.107.1152245334.squirrel@mail.his.com> Message-ID: <659B0B80B306CF62B46C5F91@lewes.staff.uscs.susx.ac.uk> --On 7 July 2006 00:08:54 -0400 Brad Knowles wrote: > In fact, I honestly believe that many of them > actively work to break their websites on all other types of browsers and > platforms, just so that they can force you to use Windows and Internet > Explorer. That's true. I've seen several sites that only work with Safari if I make it spoof another user agent! -- Ian Eiloart IT Services, University of Sussex From iane at sussex.ac.uk Fri Jul 7 12:23:50 2006 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 07 Jul 2006 11:23:50 +0100 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: <44ADF8AF.8070201@mindlace.net> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> <37460.72.177.126.107.1152245334.squirrel@mail.his.com> <44ADF8AF.8070201@mindlace.net> Message-ID: --On 7 July 2006 02:01:19 -0400 emf wrote: > Can you do me a favor and let me know how these examples work for you? > > http://tool-man.org/examples/sorting.html > > ~ethan fremen Works fine in Safari. Hopeless in a non-graphical browser, which I have used in desparation sometimes. -- Ian Eiloart IT Services, University of Sussex From iane at sussex.ac.uk Fri Jul 7 12:26:24 2006 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 07 Jul 2006 11:26:24 +0100 Subject: [Mailman-Developers] Accessible DOM manipulations In-Reply-To: <44AD7666.6000502@mindlace.net> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD7666.6000502@mindlace.net> Message-ID: <41660123DF2A74BFB44420AD@lewes.staff.uscs.susx.ac.uk> --On 6 July 2006 16:45:26 -0400 emf wrote: > > Can you help me understand the basis for this claim? I have looked into > the matter somewhat deeply and this works in every browser I have come > across that supports JavaScript: And the ones that don't? -- Ian Eiloart IT Services, University of Sussex From barry at python.org Fri Jul 7 14:21:16 2006 From: barry at python.org (Barry Warsaw) Date: Fri, 7 Jul 2006 08:21:16 -0400 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> Message-ID: <156A4653-D4F5-42F9-B1F7-09E7D6AB7AEA@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 7, 2006, at 6:13 AM, Ian Eiloart wrote: > One reason we might choose to switch off client side scripting is > so that > we can support our 20,000 odd users without having to worry about > which > view of Mailman they're seeing. We'll probably resist that, but our > front > line support would probably prefer a single interface for everyone > - and > that would necessarily be the java free interface. Just to be clear, you meant JavaScript, not Java. No one's proposing to use any client-side Java (hopefully). That's a whole 'nother cup of Joe. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK5RwnEjvBPtnXfVAQJHLAP/cTStX6Lg/UpE83MaZsPGZCsuZ8ZJ5G87 UepxfGU/4aN2I80NbQ2FNGsmokwBXtrqD9ZtgnHRoKZ57lGUCknIcLJrDUOG894W 7e8Oj2PPs8zjLsIG/E6RTQr4SJVGxL08wiZxu76znAlq/pvr1X9p8G35rREZRzU8 RvdkWmPDHuE= =4mvZ -----END PGP SIGNATURE----- From barry at python.org Fri Jul 7 14:25:13 2006 From: barry at python.org (Barry Warsaw) Date: Fri, 7 Jul 2006 08:25:13 -0400 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think it's time to put this thread to rest for now. I'm convinced Ethan understands and is sympathetic to the whole JS-vs-noJS issue. Let's give him a break so he can stop defending himself and give us something concrete to try and debate. But thanks everyone! It's was a good discussion to have! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK5SqXEjvBPtnXfVAQJv6gP/eVcOxHyifCN/603HHAqBFtPUmIneQqed hq7oq0fNzWX2i1aUUC6anD2DnMekc6FiT39zjrvFQ7AlCWOk5icNkaZ0gUvfTbT/ 3DwNQbaK9+UPtgzojvymvABN+cslCeZ24RwsxUr37T+JvQCCm6z9BbhWcPFnn9gO 1FABW2C/X5o= =/ukC -----END PGP SIGNATURE----- From lcarlson at d.umn.edu Fri Jul 7 14:54:43 2006 From: lcarlson at d.umn.edu (Laura Carlson) Date: Fri, 07 Jul 2006 07:54:43 -0500 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: References: Message-ID: <8FD8F6F3541229AC4836779E@lcarslon.d.umn.edu> Ethan wrote: >> No in-page form validation? Brad wrote: > I'd rather not, no. I have yet to see a single place on the Internet > that actually does it right, and across all platform/browser > combinations. When using Javascript for form validation, there is a right way and a wrong way. The right way (which I am sure Ethan already knows) is to use Javascript as an optional extra to improve usability. All form submissions are validated on the server. If the reader has Javascript available, an initial validation is done on the client, to check for *simple* errors such as missing information or non-numeric characters in a numeric field. This means the user gets faster feedback than waiting for a response from the server. Javascript validation should be always optional. Since the validation must be on the server anyway, it is silly to insist that the user must have Javascript. Adding Javascript validation should help some readers and hinder nobody. Best Regards, Laura ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ From lcarlson at d.umn.edu Fri Jul 7 15:07:59 2006 From: lcarlson at d.umn.edu (Laura Carlson) Date: Fri, 07 Jul 2006 08:07:59 -0500 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: References: Message-ID: <6D9AD897ECC295C64B4FE2FF@lcarslon.d.umn.edu> Bryan wrote: > I've seen WAY to much bad scripting (and I'm not implying that the > code you are going to write is going to be bad) to actually want to > implement and Javascript. I've seen a lot of bad, inaccessible scripting too. But if JavaScript is used in a device independent way to *progressively enhance* the user experience, as option, and if it degrades gracefully...all of which Ethan is aware of, then it can be a valuable tool. I'll be eager to test his implementation. Best regards, Laura ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ From lcarlson at d.umn.edu Fri Jul 7 15:10:13 2006 From: lcarlson at d.umn.edu (Laura Carlson) Date: Fri, 07 Jul 2006 08:10:13 -0500 Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: References: Message-ID: Ethan wrote: > Can you do me a favor and let me know how these examples work > for you? > > http://tool-man.org/examples/sorting.html Works great for able bodied mouse users. But how are people with mobility impairments like low dexterity (unable to use a pointing device like a mouse and instead must use keyboard or switch) able to use it? It doesn't seem to work via keyboard. WCAG Guideline 9. Design for device-independence: "Use features that enable activation of page elements via a variety of input devices. Device-independent access means that the user may interact with the user agent or document with a preferred input (or output) device -- mouse, keyboard, voice, head wand, or other. If, for example, a form control can only be activated with a mouse or other pointing device, someone who is using the page without sight, with voice input, or with a keyboard or who is using some other non-pointing input device will not be able to use the form." [1] Best Regards, Laura [1] http://www.w3.org/TR/WCAG10/#gl-device-independence ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ From brad at stop.mail-abuse.org Sat Jul 8 06:06:57 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat, 8 Jul 2006 00:06:57 -0400 (EDT) Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: <44ADF249.30606@mindlace.net> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> <37460.72.177.126.107.1152245334.squirrel@mail.his.com> <44ADF249.30606@mindlace.net> Message-ID: <33042.72.177.126.107.1152331617.squirrel@mail.his.com> Ethan wrote: > Have you used http://wiki.list.org/ ? Is it "flat out broken" or "slow > and distracting"? I find it has a few bugs, but mostly it works well. I have tried to use Confluence, yes. Not all that successfully, however. It seems to be an improvement over TWiki, but that's not saying much. > Here's a specific example that works well for me: Does the drag/drop of > boxes on the customized google home page not work for you? You don't > have to sign in to try it, and it allows drag/drop reordering for me in > Safari just fine, and way more intuitively than resubmitting the page > after clicking on buttons. I had never tried that particular feature of Google, but I'm not particularly impressed by it. And if the choice is to send a whole bunch of stuff to the other end and then hide most of it or to simply not send it at all, I vote for not sending it. If you read the Slashdot article that I referenced in another message, I believe you'll find that it's the Google people who are saying that the bottleneck in most cases is not the network, but is actually the amazingly low-end Pentium machines that people have at home, and that we (they) have to work hard to avoid overtaxing those systems. > So you have no constructive feedback, nor a sufficiently detailed > critique that I can even address your concerns. I'm not sure what you > would have me do with your advice, beyond my already existing commitment > to make the page work without JavaScript. It's not just making sure that the page will work without JavaScript. It's also making sure that the JavaScript which is added is relatively simple and unlikely to break when viewed/used in unexpected or unknown browsers, and will be likely to continue to work in all future browsers and browser versions. It's also not pushing things too far, because I might end up browsing a Mailman admin site with my Treo 650 with JavaScript turned on, across a slow spotty GPRS connection, and I still need this 320x320 screen to be useful when trying to do some emergency list maintenance away from home. > * IE 5+, Mozilla (any), Safari from 1.0+ and any other KHTML browsers, > JAWS 6+, Opera 6+, Lynx, Links. All in any combination of > Images/CSS/JavaScript off/on. You've got PCs on the brain. Or maybe not PCs, but certainly desktop computers. Don't forget about Opera Mini, Brew, the web browser on Palm from Access, the other web browsers for common PDA and phone devices, etc.... -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From brad at stop.mail-abuse.org Sat Jul 8 06:16:24 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat, 8 Jul 2006 00:16:24 -0400 (EDT) Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: <44ADF8AF.8070201@mindlace.net> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> <37460.72.177.126.107.1152245334.squirrel@mail.his.com> <44ADF8AF.8070201@mindlace.net> Message-ID: <33084.72.177.126.107.1152332184.squirrel@mail.his.com> Ethan wrote: > Can you do me a favor and let me know how these examples work for you? > > http://tool-man.org/examples/sorting.html It seemed to work as the author expected, using Safari 2.x under MacOS X 10.4.x. Using Blazer on my Palm Treo 650, although I enabled everything (especially including JavaScript), the supposedly draggable items were instead rendered as plain text. This is the key problem with something like JavaScript. It advertises that it works, your web application can see that JavaScript is enabled, you test it with your preferred browser(s) and everything seems okay, and you release the code. Only problem is, when it's put out there in the real world you discover that it has "interesting" failure modes with other browsers that you didn't test with. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From brad at stop.mail-abuse.org Sat Jul 8 06:32:48 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat, 8 Jul 2006 00:32:48 -0400 (EDT) Subject: [Mailman-Developers] The Philosophy of Web Use. In-Reply-To: <44ADF766.1090101@mindlace.net> References: <084E5E2F4E3B2B637E36FBEE@lcarslon.d.umn.edu> <44AC39EB.6020905@mindlace.net> <33390.72.177.126.107.1152207509.squirrel@mail.his.com> <44AD77B4.8090707@mindlace.net> <44ADCF8A.7080100@mindlace.net> <37460.72.177.126.107.1152245334.squirrel@mail.his.com> <38818.72.177.126.107.1152248313.squirrel@mail.his.com> <44ADF766.1090101@mindlace.net> Message-ID: <33520.72.177.126.107.1152333168.squirrel@mail.his.com> Ethan wrote: >> | Dollar for dollar, network-based computers are faster. > > This is incorrect, based on my experience of working in a few data > centers. > > While it is possible to buy expensive hardware today that has more > performance than the average consumer machine, hardware is getting > better faster than purchasing decisions. That's new hardware. There's tons of old hardware out there that people refuse to upgrade or replace. Why do you think that Microsoft has had such problems EOL'ing Windows 95? > Because the consumer market is both larger and growing faster than the > server market, and the machines less reliable, the average server is > older than the average client machine, and thus have less resources than > the average client. That's not my experience at all, and I've been a professional systems administrator for over sixteen years. Businesses tend to rapidly depreciate and replace hardware, much, much faster than individuals do at home -- by an order of magnitude or more, in some cases. This is why companies like Dell focus almost exclusively on the business market. > Even if you disagree with this point, there's one server for many > clients; the amount of resources available to devote to the task of an > individual user's web experience is almost always greater on their end > of the pipe. True, the number and power of clients can always overwhelm the number and power of servers. The SETI at Home project certainly taught us that. And we knew that lesson at AOL before SETI at Home came alone, because there were a number of incidences when a surprisingly small number of attackers could do serious damage to the service. But just because the number and power of clients can overwhelm the number and power of servers doesn't mean that they necessarily will always do so. If that were the case, then we'd all be permanently out of work. Moreover, although you might be right in general, you cannot assume that each specific user will always be in that same sort of situation. That would be like claiming that everyone is above average. > What it boils down to is that people perceive change at around 150msec; > very few net users get anywhere near this latency, and so for most, the > round-trip delay represents a substantial impediment to the > responsiveness of the interface. Right, and if they're running on an ancient Pentium computer with Windows 95 and their interface is dead-dog slow because you force-fed it too much stuff to process, they're not going to have a particularly good experience. The lesson that Yahoo! and Google teach is to keep everything as simple and light as humanly possible. They learned this from Colin Chapman and the guys at Lotus, whose motto was "Simplify and add lightness". That's all I'm looking for. Give me the Lotus Exige of interfaces. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From barry at python.org Sat Jul 8 20:49:31 2006 From: barry at python.org (Barry Warsaw) Date: Sat, 8 Jul 2006 14:49:31 -0400 Subject: [Mailman-Developers] Vacation work committed Message-ID: <654037C9-09A6-4ABE-A529-4CC8F5CBD63B@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've finished committing all the work that I'd completed while on vacation. Read the NEWS file or commit messages for details and please ask questions if anything doesn't make sense or looks wrong. The changes are fairly extensive and may need some additional testing. On that note, all the existing unit tests now pass! We probably need a lot more though. I'm going to continue to work on the SQLAlchemy stuff and if I get something working, I'll check that in too. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK/+O3EjvBPtnXfVAQIGkAP8DhjeHm4kK/f7n+btvCu7varvCsH2L8s/ YRqa1qK9fEsXMtoivm3iza70mBpv7XW+0NObbWGsb5y2doQE/kmkLqZdKAs4BQ9L OsqvbEJwicwUE7TRtC8sZpQqBtBaooAmDRJw2118h+Qqzu+M9kjJi6/McX2rBDDN 2ODV2mE389s= =7iy1 -----END PGP SIGNATURE----- From i at mindlace.net Sun Jul 9 21:57:30 2006 From: i at mindlace.net (emf) Date: Sun, 09 Jul 2006 15:57:30 -0400 Subject: [Mailman-Developers] soc2006-webui updated Message-ID: <44B15FAA.2000300@mindlace.net> I've (correctly, this time) merged the trunk to my branch, and checked in a bunch more xhtml. now I'm going to try finishing off the rendering component so people can start seeing what I've done and help me find any bugs/UI issues. As soon as the rendering component is done, I'm going to do some CSS and then work on the glue code. After that is all working I will bring in some of that ominous javascript. ~ethan fremen From barry at python.org Sun Jul 9 22:10:48 2006 From: barry at python.org (Barry Warsaw) Date: Sun, 9 Jul 2006 16:10:48 -0400 Subject: [Mailman-Developers] soc2006-webui updated In-Reply-To: <44B15FAA.2000300@mindlace.net> References: <44B15FAA.2000300@mindlace.net> Message-ID: <78E8518C-E82A-4807-9314-1D1AAF1F5BAE@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 9, 2006, at 3:57 PM, emf wrote: > I've (correctly, this time) merged the trunk to my branch, and checked > in a bunch more xhtml. now I'm going to try finishing off the > rendering > component so people can start seeing what I've done and help me > find any > bugs/UI issues. > > As soon as the rendering component is done, I'm going to do some > CSS and > then work on the glue code. After that is all working I will bring in > some of that ominous javascript. Thanks for the update Ethan. BTW, is anybody getting email diffs from Ethan's checkins on the mailman-checkins list? They're not getting held so I suspect that SF isn't sending them out for his branch. Or is it just me? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRLFi2XEjvBPtnXfVAQLzyQP+Ksto/fiSBU3PMjRSf1UM30nW4Y/caQjM p2nxQb74D4lCVDYY49q141tvt+tRhoz/KHBzL8dySHasTjfMn+RLYFWknII4wnEy TYnKkoUFVTov4xWeJGXC4uj8+tIIvibdY6N6xpGLeMbcMc0WAXIEar+w15JFqPoU f9UwvKRfcm4= =twYT -----END PGP SIGNATURE----- From msapiro at value.net Sun Jul 9 23:24:55 2006 From: msapiro at value.net (Mark Sapiro) Date: Sun, 9 Jul 2006 14:24:55 -0700 Subject: [Mailman-Developers] soc2006-webui updated In-Reply-To: <78E8518C-E82A-4807-9314-1D1AAF1F5BAE@python.org> Message-ID: Barry Warsaw wrote: > >BTW, is anybody getting email diffs from Ethan's checkins on the >mailman-checkins list? They're not getting held so I suspect that SF >isn't sending them out for his branch. Or is it just me? I have not gotten anything from the mailman-checkins list from Ethan's checkins. I also don't recall seeing a message from --------------------------------------- Revision: 7922 Author: pheinlein Date: 7:10:28 PM, Tuesday, July 04, 2006 Message: Several fixes and updates. ---- Modified : /trunk/mailman/messages/de/LC_MESSAGES/mailman.po --------------------------------------- but that could be due to any number of things including my just not remembering that I got it. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From i at mindlace.net Mon Jul 10 00:05:06 2006 From: i at mindlace.net (emf) Date: Sun, 09 Jul 2006 18:05:06 -0400 Subject: [Mailman-Developers] soc2006-webui updated In-Reply-To: <78E8518C-E82A-4807-9314-1D1AAF1F5BAE@python.org> References: <44B15FAA.2000300@mindlace.net> <78E8518C-E82A-4807-9314-1D1AAF1F5BAE@python.org> Message-ID: <44B17D92.3030007@mindlace.net> Barry Warsaw wrote: > BTW, is anybody getting email diffs from Ethan's checkins on the > mailman-checkins list? They're not getting held so I suspect that SF > isn't sending them out for his branch. Or is it just me? I don't get any, that's for sure. ~ethan fremen From barry at python.org Mon Jul 10 16:41:26 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 10 Jul 2006 10:41:26 -0400 Subject: [Mailman-Developers] soc2006-webui updated In-Reply-To: <44B17D92.3030007@mindlace.net> References: <44B15FAA.2000300@mindlace.net> <78E8518C-E82A-4807-9314-1D1AAF1F5BAE@python.org> <44B17D92.3030007@mindlace.net> Message-ID: <27B22099-270D-41CE-81D5-A6940C684E52@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 9, 2006, at 6:05 PM, emf wrote: > Barry Warsaw wrote: > >> BTW, is anybody getting email diffs from Ethan's checkins on the >> mailman-checkins list? They're not getting held so I suspect that SF >> isn't sending them out for his branch. Or is it just me? > > I don't get any, that's for sure. I don't see any in the admin interface, but it's set up to auto- reject. I just changed that to hold so we'll see if the messages are actually getting there or not after your next commit (if you want to do a test checking, feel free!). If they aren't even getting there, then we'll have to contact SF to get that fixed. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRLJnF3EjvBPtnXfVAQJz2AP+PJJetAaov8dI6tASKclVBmcFmYNpaobP BMEzfIqQu1pxKn/vK/MFymhRY3HM2+dlhJw6KWWVDJ5idP/v65otgJPALc5xAFUE YU7hoylE0ro/kROyfNgPMDgP0VQtjWj5IBa87tm7lKmUJnpU22EGSpJgObPd1Wh9 k5JQe+enTmg= =R2cc -----END PGP SIGNATURE----- From msapiro at value.net Mon Jul 10 17:23:48 2006 From: msapiro at value.net (Mark Sapiro) Date: Mon, 10 Jul 2006 08:23:48 -0700 Subject: [Mailman-Developers] soc2006-webui updated In-Reply-To: <27B22099-270D-41CE-81D5-A6940C684E52@python.org> Message-ID: Barry Warsaw wrote: > >I don't see any in the admin interface, but it's set up to auto- >reject. I just changed that to hold so we'll see if the messages are >actually getting there or not after your next commit (if you want to >do a test checking, feel free!). If they aren't even getting there, >then we'll have to contact SF to get that fixed. I don't see mindlace23 at users.sourceforge.net on the roster at . Is that the issue? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at python.org Mon Jul 10 17:25:57 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 10 Jul 2006 11:25:57 -0400 Subject: [Mailman-Developers] soc2006-webui updated In-Reply-To: References: Message-ID: <6D5E8AE7-F004-41A3-BF4F-4E23192C23E4@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 10, 2006, at 11:23 AM, Mark Sapiro wrote: > I don't see mindlace23 at users.sourceforge.net on the roster at > . Is that the > issue? That's my theory. His commits got auto-rejected and SF threw them away. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRLJxhXEjvBPtnXfVAQINpQQAstalmnmVwO+6Cg28laTtZ3uq+vmtYQBx vWYl8CZ0jco+eX6WnkfrQYyD+5GeXqtv+LbBSwW1cnTuSzaTdwiQeM0ZjznhQf7T V9u6TX6Y4PN6sCo6azylZK0bhTMqf0TWN4XBowX2L2a+0fLJFth1twQ4dzE65+jE bYDLnzHw3YQ= =NujZ -----END PGP SIGNATURE----- From qralston+ml.mailman-developers at andrew.cmu.edu Wed Jul 12 17:54:56 2006 From: qralston+ml.mailman-developers at andrew.cmu.edu (James Ralston) Date: Wed, 12 Jul 2006 11:54:56 -0400 Subject: [Mailman-Developers] effects of not rewriting the Sender header Message-ID: <88E66B40DA135D237282B6EB@farslayer.l33tskillz.org> As a follow-up to the Sender header discussion back on 2006-04/05... On 2006-06-17, we disabled Sender header rewriting at our site, using the attached patch. Since then, we've received no complaints whatsoever from our users about bounces not being caught, and the complaints about recipients using Outlook seeing "bounce" addresses have ceased. Based on our experiences, I'd strongly recommend that this patch be applied to the official Mailman distribution. Regards, James -------------- next part -------------- --- mailman-2.1.5.1/Mailman/Handlers/SMTPDirect.py.sender-header 2004-01-22 18:02:07.000000000 -0500 +++ mailman-2.1.5.1/Mailman/Handlers/SMTPDirect.py 2006-06-16 18:39:35.000000000 -0400 @@ -340,17 +340,23 @@ def bulkdeliver(mlist, msg, msgdata, envsender, failures, conn): - # Do some final cleanup of the message header. Start by blowing away - # any the Sender: and Errors-To: headers so remote MTAs won't be - # tempted to delivery bounces there instead of our envelope sender - # - # BAW An interpretation of RFCs 2822 and 2076 could argue for not touching - # the Sender header at all. Brad Knowles points out that MTAs tend to - # wipe existing Return-Path headers, and old MTAs may still honor - # Errors-To while new ones will at worst ignore the header. - del msg['sender'] + # Do some final cleanup of the message header. Start by blowing away any + # Errors-To: headers so remote MTAs won't be tempted to delivery bounces + # there instead of our envelope sender. + # + # Previously, we also blew away any Sender: headers, and added a new + # Sender: header with our envelope sender. However, this behavior seems to + # cause more problems than it solves, because various MUAs will include the + # Sender address in a reply-to-all, which is not only confusing to + # subscribers, but can actually disable/unsubscribe them from lists, + # depending on how often they accidentally reply to it. + # + # The drawback of not touching the Sender: header is that some MTAs might + # still send bounces to it, so by not trapping it, we can miss bounces. + # (Or worse, MTAs might send bounces to the From: address if they can't + # find a Sender: header.) But at least for now, we're going to take our + # chances with leaving the Sender: header alone. del msg['errors-to'] - msg['Sender'] = envsender msg['Errors-To'] = envsender # Get the plain, flattened text of the message, sans unixfrom msgtext = msg.as_string() From barry at python.org Wed Jul 12 18:19:59 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 12 Jul 2006 12:19:59 -0400 Subject: [Mailman-Developers] effects of not rewriting the Sender header In-Reply-To: <88E66B40DA135D237282B6EB@farslayer.l33tskillz.org> References: <88E66B40DA135D237282B6EB@farslayer.l33tskillz.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 12, 2006, at 11:54 AM, James Ralston wrote: > As a follow-up to the Sender header discussion back on 2006-04/05... > > On 2006-06-17, we disabled Sender header rewriting at our site, using > the attached patch. > > Since then, we've received no complaints whatsoever from our users > about bounces not being caught, and the complaints about recipients > using Outlook seeing "bounce" addresses have ceased. > > Based on our experiences, I'd strongly recommend that this patch be > applied to the official Mailman distribution. Thanks for the feedback James. Have you seen any problems with processing legitimate bounces to addresses that don't exist? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRLUhL3EjvBPtnXfVAQL/uAP8C0T2DGSWGFeBEk2g+x6SJWTb7zro7C7I UZvVtf3cB6Hy8fmgExADk9TWHjbR/rHpp7ILHIBH4pNCENLsTPWjjVbTgDnurVQh 6RHnD1OunrRJwFO0OTv8XA4VHbdaBIwuEjblxMSVd4i10ORniYZp6V89nG6M/BU1 J6ys9rto+KI= =4ohI -----END PGP SIGNATURE----- From lcarlson at d.umn.edu Thu Jul 13 14:29:15 2006 From: lcarlson at d.umn.edu (Laura Carlson) Date: Thu, 13 Jul 2006 07:29:15 -0500 Subject: [Mailman-Developers] Section 508 checklist updated Message-ID: fyi...WebAIM's handy Section 508 checklist has been updated. A portion of it is about scripts: http://www.webaim.org/standards/508/checklist.php#two btw...I want to invite anyone interested in receiving weekly news and information about web design and development to join the webdev listserv and receive the Web Design Update newsletter. It is a plain text email digest dedicated to disseminating news and information about web design and development with emphasis on elements of user experience, accessibility, CSS, usability, javascript, web standards and more. I try to send out an issue on a weekly basis. Whenever I link new articles to the Web Design Reference site , a WEB DESIGN UPDATE newsletter message is sent to the listserv. To subscribe visit: http://www.d.umn.edu/goto/webdevlist Best regards, Laura ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ From alisdair at epcc.ed.ac.uk Mon Jul 17 11:53:54 2006 From: alisdair at epcc.ed.ac.uk (Alisdair Tullo) Date: Mon, 17 Jul 2006 10:53:54 +0100 (BST) Subject: [Mailman-Developers] Integrating Mailman with a single sign-on service Message-ID: Hi, Here at the University of Edinburgh we have a single sign-on service based on Cosign ( http://www.umich.edu/~umweb/software/cosign/ ). I've selected Mailman as the mailing list software for a project I'm working on, and I'd like to integrate it with Cosign if possible. I have a few questions about Mailman, if someone familiar with the code can answer them I'd be very grateful. 1. Is there a top-level design document for Mailman? 2. Cosign gives a username in REMOTE_USER in each HTTP request. My intent is to get users to sign up by entering this username and an email address, then the web interface for Mailman would take the value of REMOTE_USER and map it to the email address. Which area of the source should I be looking at? 3. Would someone familiar with the Mailman web interface be willing to help further and answer more detailed questions as I progress? I've spent some time already looking through the source, but as you can appreciate it's tricky working out where to get started. Cheers, Alisdair | Alisdair Tullo :: - epcc - :: alisdair at epcc.ed.ac.uk | | University of Edinburgh :: JCMB 3309 :: 0131 650 5023 | From msapiro at value.net Mon Jul 17 19:27:40 2006 From: msapiro at value.net (Mark Sapiro) Date: Mon, 17 Jul 2006 10:27:40 -0700 Subject: [Mailman-Developers] Integrating Mailman with a single sign-onservice In-Reply-To: Message-ID: Alisdair Tullo wrote: > >Here at the University of Edinburgh we have a single sign-on service based >on Cosign ( http://www.umich.edu/~umweb/software/cosign/ ). I've selected >Mailman as the mailing list software for a project I'm working on, and I'd >like to integrate it with Cosign if possible. > >I have a few questions about Mailman, if someone familiar with the code >can answer them I'd be very grateful. > >1. Is there a top-level design document for Mailman? No. There is a description of message flow through Mailman in comments at the beginning of Mailman/Queue/IncomingRunner.py, but that's about it. >2. Cosign gives a username in REMOTE_USER in each HTTP request. My intent >is to get users to sign up by entering this username and an email address, >then the web interface for Mailman would take the value of REMOTE_USER and >map it to the email address. Which area of the source should I be looking >at? The Mailman web interface is entirely (with the exception of public archives which link directly to static html pages) supported by a set of CGI modules. These are accessed via wrappers, but the actual work is done in the various python modules in Mailman/Cgi/. These modules, with the exception of Auth.py which generates the Admin/Moderator login page, have a one to one correspondence with the URIs that access them. E.g. http://www.example.com/mailman/admin/... is processed by admin.py and so forth. >3. Would someone familiar with the Mailman web interface be willing to >help further and answer more detailed questions as I progress? You can post your questions to this list, and I and others will do our best to answer. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From brad at python.org Mon Jul 17 19:01:21 2006 From: brad at python.org (Brad Knowles) Date: Mon, 17 Jul 2006 12:01:21 -0500 Subject: [Mailman-Developers] Integrating Mailman with a single sign-on service In-Reply-To: References: Message-ID: At 10:53 AM +0100 2006-07-17, Alisdair Tullo wrote: > I have a few questions about Mailman, if someone familiar with the code > can answer them I'd be very grateful. Speaking as one of the list co-moderators, we normally try to keep the "questions" type stuff on the mailman-users mailing list, where you will find many of the Mailman developers are also subscribed. This particular message seemed to be kind of borderline for me, so I went ahead and approved it in the hope that we would get into discussion of Python modifications you're making or would like to make to support your requirements. Other than that, I'm usually more of an observer on this list, and I'm afraid I don't have any answers for you. I'll let someone else that is more knowledgeable about the code try to address your questions. -- Brad Knowles Member of the Python.org Postmaster Team Co-moderator of mailman-users and mailman-developers mailing lists From i at mindlace.net Tue Jul 18 00:04:52 2006 From: i at mindlace.net (emf) Date: Mon, 17 Jul 2006 18:04:52 -0400 Subject: [Mailman-Developers] Integrating Mailman with a single sign-on service In-Reply-To: References: Message-ID: <44BC0984.9070705@mindlace.net> Alisdair Tullo wrote: > 2. Cosign gives a username in REMOTE_USER in each HTTP request. My intent > is to get users to sign up by entering this username and an email address, > then the web interface for Mailman would take the value of REMOTE_USER and > map it to the email address. Which area of the source should I be looking > at? Right now that's pretty hard-coded. I'm working to improve the web interface. For a number of reasons, I'm going to switch from the cookie auth to standard (digest) auth. I intend to implement a handler that will accept REMOTE_USER as authoritative; however, my implementation will expect REMOTE_USER to be an email address. So, minimally what you'd need to do is provide a bit of code that does the user/email address mapping, and it would hook into my authentication handler. I'll check in some code that at least does this stuff by wendesday. We're going to go further down the road to supporting abstract users (as opposed to list members) for MM 3.0, so you probably won't have to support that bit of code for long. > 3. Would someone familiar with the Mailman web interface be willing to > help further and answer more detailed questions as I progress? Yes. I am knee deep in it now, and misery loves company :) ~ethan fremen p.s. my kvetches about the existing interface shouldn't be taken as a diss to those who implemented it; for the time it was pretty forward thinking. From sfeng at stanford.edu Tue Jul 18 03:33:47 2006 From: sfeng at stanford.edu (Xueshan Feng) Date: Mon, 17 Jul 2006 18:33:47 -0700 Subject: [Mailman-Developers] Integrating Mailman with a single sign-onservice In-Reply-To: References: Message-ID: <1153186427.14205.73.camel@hoss.stanford.edu> Alisdair, I have done Webauth using Stanford WebAuth (http://webauth.stanford.edu) for Mailman package. Basically users can signup using any form of valid @stanford.edu address, and I use Stanford Directory to map the name to a user's id. This information is kept in the mailman mailing list's pickle db, as an additional dictionary field. Python codes under /usr/lib/mailman/Mailman/Cgi are changed so that if a person use @stanford.edu address, they are redirected to webauthed page for suoptions, surosters, admin, suprivate archives etc. I can make the patches (40+) or the Mailman Debian package that has Stanford webauth patches, and local configurations available if any one is insterested. It won't work for others as is, but at least you can take a look at one of the ways to do webauth integration. I am new to the list and am not sure what's the best way to share this, but you can always contact me in person. Xueshan ------------------------------ Xueshan Feng (aka. Susan Feng) Shared Services, ITSS Stanford University, CA 94305-3090 255 Panama St. Room 157, Polya Hall Stanford University Stanford, CA 94305-4136 On Mon, 2006-07-17 at 10:27 -0700, Mark Sapiro wrote: > Alisdair Tullo wrote: > > > >Here at the University of Edinburgh we have a single sign-on service based > >on Cosign ( http://www.umich.edu/~umweb/software/cosign/ ). I've selected > >Mailman as the mailing list software for a project I'm working on, and I'd > >like to integrate it with Cosign if possible. > > > >I have a few questions about Mailman, if someone familiar with the code > >can answer them I'd be very grateful. > > > >1. Is there a top-level design document for Mailman? > > > No. There is a description of message flow through Mailman in comments > at the beginning of Mailman/Queue/IncomingRunner.py, but that's about > it. > > > >2. Cosign gives a username in REMOTE_USER in each HTTP request. My intent > >is to get users to sign up by entering this username and an email address, > >then the web interface for Mailman would take the value of REMOTE_USER and > >map it to the email address. Which area of the source should I be looking > >at? > > > The Mailman web interface is entirely (with the exception of public > archives which link directly to static html pages) supported by a set > of CGI modules. These are accessed via wrappers, but the actual work > is done in the various python modules in Mailman/Cgi/. These modules, > with the exception of Auth.py which generates the Admin/Moderator > login page, have a one to one correspondence with the URIs that access > them. E.g. http://www.example.com/mailman/admin/... is processed by > admin.py and so forth. > > > >3. Would someone familiar with the Mailman web interface be willing to > >help further and answer more detailed questions as I progress? > > > You can post your questions to this list, and I and others will do our > best to answer. > From qralston+ml.mailman-developers at andrew.cmu.edu Wed Jul 19 19:08:26 2006 From: qralston+ml.mailman-developers at andrew.cmu.edu (James Ralston) Date: Wed, 19 Jul 2006 13:08:26 -0400 Subject: [Mailman-Developers] effects of not rewriting the Sender header In-Reply-To: References: <88E66B40DA135D237282B6EB@farslayer.l33tskillz.org> Message-ID: On 2006-07-12 at 12:19-04 Barry Warsaw wrote: > On Jul 12, 2006, at 11:54 AM, James Ralston wrote: > > > As a follow-up to the Sender header discussion back on > > 2006-04/05... > > > > On 2006-06-17, we disabled Sender header rewriting at our site, > > using the attached patch. > > > > Since then, we've received no complaints whatsoever from our users > > about bounces not being caught, and the complaints about > > recipients using Outlook seeing "bounce" addresses have ceased. > > > > Based on our experiences, I'd strongly recommend that this patch > > be applied to the official Mailman distribution. > > Thanks for the feedback James. Have you seen any problems with > processing legitimate bounces to addresses that don't exist? Here's our count of bounces without discernable addresses so far for the year: Month count --------------- 2006-01 10 2006-02 32 2006-03 36 2006-04 32 2006-05 16 2006-06 12 2006-07 6 I'd like to see the data through, say, September before drawing any firm conclusions, but we definitely have *not* seen any sharp increase in the number of bounces without discernable addresses. As an aside, we average about 3,259 bounces per month across all lists, so having only (e.g.) 12 unrecognized bounces is actually a very impressive number (about 0.37%). James From i at mindlace.net Sun Jul 23 22:30:38 2006 From: i at mindlace.net (emf) Date: Sun, 23 Jul 2006 16:30:38 -0400 Subject: [Mailman-Developers] Anyone have a pickle / mbox to spare? Message-ID: <44C3DC6E.90806@mindlace.net> Gentlebeings, It would sincerely help me if I could test my UI against actual mailman pickles to make sure I can deal with vagaries of configuration, etc. I would use them on a local machine; for collaboration purposes the data would be as available to the public as your current installation, though it wouldn't accept or send mail. I'd be happy to provide a script to randomize all users passwords before you sent it over, but would prefer that the email addresses stay valid. I don't need generated archive files; just list pickles and mbox files, if you've been generating them. If you have at least one 'private' list's that you'd be willing to share, that would be ideal, though I have some lying about. I can accept attachments of arbitrary size, or arrange another method of transit. Thanks for your help, ~ethan fremen http://wiki.list.org/display/DEV/Summer+of+Code From carbonnb at gmail.com Mon Jul 24 01:18:03 2006 From: carbonnb at gmail.com (Bryan Carbonnell) Date: Sun, 23 Jul 2006 19:18:03 -0400 Subject: [Mailman-Developers] Anyone have a pickle / mbox to spare? In-Reply-To: <44C3DC6E.90806@mindlace.net> References: <44C3DC6E.90806@mindlace.net> Message-ID: On 7/23/06, emf wrote: > It would sincerely help me if I could test my UI against actual mailman > pickles to make sure I can deal with vagaries of configuration, etc. > I'd be happy to provide a script to randomize all users passwords before > you sent it over, but would prefer that the email addresses stay valid. > > I don't need generated archive files; just list pickles and mbox files, > if you've been generating them. I've got a 213MB mbox, and associated pickle although it's a public list. Just let me know where to send it. -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From i at mindlace.net Mon Jul 24 03:17:17 2006 From: i at mindlace.net (emf) Date: Sun, 23 Jul 2006 21:17:17 -0400 Subject: [Mailman-Developers] Decorators in MailList.py .... Message-ID: <44C41F9D.1060306@mindlace.net> Hallo! I am noticing there are decorators in MailList.py... does that mean I can use them? ~ethan From barry at python.org Mon Jul 24 05:11:59 2006 From: barry at python.org (Barry Warsaw) Date: Sun, 23 Jul 2006 23:11:59 -0400 Subject: [Mailman-Developers] Decorators in MailList.py .... In-Reply-To: <44C41F9D.1060306@mindlace.net> References: <44C41F9D.1060306@mindlace.net> Message-ID: <93B4EFAE-CC1E-466E-8277-C685F30681C2@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 23, 2006, at 9:17 PM, emf wrote: > Hallo! I am noticing there are decorators in MailList.py... does that > mean I can use them? Um, oops! I think we've decided on Python 2.3 for Mailman 2.2. I'd still like to settle on Python 2.4 but the last time we talked about this the consensus was that too many current distros still include just 2.3. If that's the case, we'll have to get rid of these decorators. :( - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRMQ6f3EjvBPtnXfVAQLewgQAh/IJkEW9Tosj60YzYOC+aq/3bnT8R3P6 jc54my8FIDz9lMtGalgpDlCx/VdVHJ5TfRduLgNRWW5t+tvPZPDvhqR6T619khsT n9vxmAsBivgvIq2IlPLKq+dpMpA4tuFHvnmUoVZSg59ArvuYCbW1savSnztXKuko /sOzdSEKPxM= =1nix -----END PGP SIGNATURE----- From i at mindlace.net Mon Jul 24 19:53:15 2006 From: i at mindlace.net (emf) Date: Mon, 24 Jul 2006 13:53:15 -0400 Subject: [Mailman-Developers] Bounces, Pickles, Coding Styles Oh My Message-ID: <44C5090B.2080509@mindlace.net> Calloo Callay! So I'm spelunking about. I don't like the way the current UI doesn't tell the admin about bounciness of users, so I was looking to see what is known. After some non-trivial meditation on BounceRunner.py I think I know the difference between verp_probe and verp_bounce, despite not quite knowing what VERP means, the comment string for the two functions being identical, and the bodies of them being identical as well save a tiny little memory stanza. Would someone be willing to change verp_probe's docstring to more clearly illustrate its function? Also, I'm finding a fair number of files that aren't pep8/styleguide.txt happy. anyone care if I at least correct tab/space mixing, and/or make it otherwise style-guide correct? As much as I appreciate the principles of code-hiding, it's been a bit of a pain to use the interpreter to figure out what is stored in a pickle. Since I can't read the pickle file with my eyes, perhaps a little less obscuration might be OK? Like, list.members['i at mindlace.net'] doesn't work. In fact, I can't find any function that gives me a member in its entirety. It would help me if I could just see the underlying data; any suggestions on how? ~ethan From i at mindlace.net Mon Jul 24 19:54:43 2006 From: i at mindlace.net (emf) Date: Mon, 24 Jul 2006 13:54:43 -0400 Subject: [Mailman-Developers] Password reminders "going away" in 2.2 Message-ID: <44C50963.4010508@mindlace.net> So does this mean I don't have to implement that bit of preferences UI? ~ethan From barry at python.org Tue Jul 25 14:13:06 2006 From: barry at python.org (Barry Warsaw) Date: Tue, 25 Jul 2006 08:13:06 -0400 Subject: [Mailman-Developers] Password reminders "going away" in 2.2 In-Reply-To: <44C50963.4010508@mindlace.net> References: <44C50963.4010508@mindlace.net> Message-ID: <6C74D1AC-1343-430C-94C6-C7D2AD84913F@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 24, 2006, at 1:54 PM, emf wrote: > So does this mean I don't have to implement that bit of preferences > UI? Correct. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRMYK0nEjvBPtnXfVAQLJkgQAjtmWSfRGI9ZGX8iWx6rTkK+ktmTXdvBX f0aM+3D2tkO6A+BmvJ7Jz2aybjwTOxxMStmHEzAp1mZ/oEWJofDIzkNL/qpwWyRx QICPyjX5/0AKXFVGJD3RvB9YiQ/UOzVNpJkcFMcsKqyfMUg7+ewGJag560Db9ar0 eWSrD06EPuM= =lBis -----END PGP SIGNATURE----- From qralston+ml.mailman-developers at andrew.cmu.edu Fri Jul 28 23:36:31 2006 From: qralston+ml.mailman-developers at andrew.cmu.edu (James Ralston) Date: Fri, 28 Jul 2006 17:36:31 -0400 Subject: [Mailman-Developers] suggested improvement for Mailman's bounce processing Message-ID: <77D33A972456F01D4CD978F4@emerald.sei.cmu.edu> Consider the following situation: 1. Some users at our site are subscribed to external Mailman-managed mailing lists that perform automatic bounce processing. 2. Because the list owners are either unwilling are unable to protect the lists from spam, the lists receive a fair amount of spam. 3. Our MX servers are configured to reject outright incoming messages that are obviously spam. Most of you can see the impending train wreck already, but for completeness' sake, here's the problem: 1. Mailman distributes obvious spam to the list. 2. We detect the spam and reject it during the SMTP dialog with a 550 reply code (5.7.0 extended status code). 3. Mailman receives a DSN message because we bounced the message. 4. Mailman assumes that the bounce is due to the recipient's address being invalid, and disables the subscription. 5. Much wailing and gnashing of teeth ensues. >From looking at Bouncers/DSN.py, although Mailman takes the time to pick apart each message/delivery-status subpart and extract the "action" field, it blissfully ignores the "status" field, which must be present and must contain the extended status code which generated the DSN. The subject sub-code of the extended status code classifies the status as follows: X.0.XXX Other or Undefined Status X.1.XXX Addressing Status X.2.XXX Mailbox Status X.3.XXX Mail System Status X.4.XXX Network and Routing Status X.5.XXX Mail Delivery Protocol Status X.6.XXX Message Content or Media Status X.7.XXX Security or Policy Status Of these, some subject sub-codes (e.g.: X.2.XXX) pertain directly to the validity of the destination address. But some do *not* pertain to the destination address: for example, X.6.XXX clearly means that the *content* of the message (not the source or destination address) caused the DSN. Regardless, Mailman ignores all of the status field information: if the action is "failed", Mailman counts it as a bounce, and that's that. IMHO, this is an error. I propose modifying Bouncers/DSN.py as follows: 1. Mailman tries to extract the status field from message/delivery-status subpart. 2. If Mailman cannot extract the status field, it operates solely on the action field. 2. If Mailman can extract the status field, and the subject sub-code is X.6.XXX or X.7.XXX, Mailman assumes that the DSN was generated by the fluke content of a specific message, and ignores the DSN. I admit that this algorithm isn't perfect. But I think it's better than what Mailman does currently, which is to ignore the status field entirely. Thoughts? Arguments? James From brad at stop.mail-abuse.org Sat Jul 29 04:31:29 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri, 28 Jul 2006 21:31:29 -0500 Subject: [Mailman-Developers] suggested improvement for Mailman's bounce processing In-Reply-To: <77D33A972456F01D4CD978F4@emerald.sei.cmu.edu> References: <77D33A972456F01D4CD978F4@emerald.sei.cmu.edu> Message-ID: At 5:36 PM -0400 2006-07-28, James Ralston wrote: > I admit that this algorithm isn't perfect. But I think it's better > than what Mailman does currently, which is to ignore the status field > entirely. Unfortunately, there are a whole host of seriously broken MTAs out there, and seriously broken configurations of otherwise good MTAs, and many sites return totally bogus status codes. If everyone read and understood the RFCs half as well as you have done, then there wouldn't be any problem. But that's not what happens. In many cases, site admins will blindly copy stuff from somewhere else that was horribly broken to begin with and won't understand what's wrong with it before they do the cut-n-paste operation. That said, I would not be opposed to seeing more data on this subject, and possibly giving site admins or list admins an option they can enable that would allow Mailman to pay attention to the status codes. Once that's out there, we could let various people try it out and see how it works in the field, and I would be a very happy guy if I were to be proven wrong in this case. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See . From barry at python.org Sun Jul 30 21:44:08 2006 From: barry at python.org (Barry Warsaw) Date: Sun, 30 Jul 2006 15:44:08 -0400 Subject: [Mailman-Developers] [Python-Dev] Py2.5 release schedule In-Reply-To: References: <44C9A184.7030701@ewtllc.com> <200607281539.50794.anthony@interlink.com.au> Message-ID: <3E70BA16-8DAA-487D-9901-B1597D912222@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Re: Python 2.5 compatibility On Jul 28, 2006, at 8:57 AM, Barry Warsaw wrote: > +1. It would give me more type to port and test a few of my > applications to the new version. > > I'm still working on Mailman but the most painful thing so far has > been the conversion of exceptions to new-style classes, and even > that wasn't /too/ painful. I believe I've finished porting Mailman to Python 2.5. None of the issues were insurmountable, but here they are FTR: 1) Exceptions are new-style classes but Mailman was doing one specific test against the type of an object to see if it needed to be instantiated. This test was written as: if isinstance(obj, ClassType) which fails in Python 2.5. I actually rewrote it like so: if isinstance(obj, ClassType) or isinstance(obj, type(type)) in MM2.1 because it has to be backward compatible to Python 2.1. 2) There was one place where I was commonly raising a string and that generates deprecation warnings, so I changed that to a class. There are a few other legacy string exceptions defined in the code, but they are rarely used and should all get rewritten as well. 3) Cookie.py's repr changed so that trailing semicolons are no longer output on the end of text lines. I understand this change was made so that Python cookies were more RFC compliant, but it broke some homegrown cookie text splitting we were doing. I changed this code to split on lines first. All in all, not too bad although the Cookie.py change took a while to track down! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRM0MDnEjvBPtnXfVAQJ9ZAP/VdtM79SXgx7s/X0aEIu4HDZva7TkYyi6 dRzlgAtEV5BN1yYn+vzw8PBCtdy+9N3yYtv/zqdQP54mZDjsaGaNw6MiS0jsETRy 248hj3otL/00WTrKWh8/OvDlLW8KUNQI4MWBOMKJ/TqYW5Es4fJGEMtbO/xqGXXD /wgWmmLOOAE= =Mu8m -----END PGP SIGNATURE----- From iane at sussex.ac.uk Mon Jul 31 11:56:41 2006 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 31 Jul 2006 10:56:41 +0100 Subject: [Mailman-Developers] suggested improvement for Mailman's bounce processing In-Reply-To: References: <77D33A972456F01D4CD978F4@emerald.sei.cmu.edu> Message-ID: --On 28 July 2006 21:31:29 -0500 Brad Knowles wrote: > At 5:36 PM -0400 2006-07-28, James Ralston wrote: > >> I admit that this algorithm isn't perfect. But I think it's better >> than what Mailman does currently, which is to ignore the status field >> entirely. > > Unfortunately, there are a whole host of seriously broken MTAs out > there, and seriously broken configurations of otherwise good MTAs, > and many sites return totally bogus status codes. I don't see how that could create a problem. The worst thing that could happen is that someone remains subscribed to a list when they should not. Alternately, they could be unsubscribed because their MTA is returning the wrong error codes - but then that would give their postmaster a good reason to fix the error codes. In this case, they'd be unsubscribed as things stand anyway. -- Ian Eiloart IT Services, University of Sussex From bob at nleaudio.com Mon Jul 31 13:57:19 2006 From: bob at nleaudio.com (Bob Puff) Date: Mon, 31 Jul 2006 07:57:19 -0400 Subject: [Mailman-Developers] suggested improvement for Mailman's bounce processing In-Reply-To: References: <77D33A972456F01D4CD978F4@emerald.sei.cmu.edu> Message-ID: <20060731115353.M79964@nleaudio.com> Whis may be slightly OT, but I just encountered a major problem with the bounce processing on MM 2.16. Had a large list used for monthly announcements. I realized that since messages only went out once per month, I needed to tighten up the default bounce scoring system, so I set it to remove the user after 1 bounce (score of 1.0). The following day, I saw excessive CPU load on the box, so I checked into it. It was unsubscribing everyone from the list, saying due to a bounce in 2005, they were being unsubscribed! The strange thing is that no posting had been done to this particular list during the time of the change of the bounce parameters, and the unsubscriptions. BOb