Re: [Mailman-Developers] Parsing and Rendering rfc8222
* 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 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Turning off dynamic JavaScript
--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/ ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
[Mailman-Developers] Parsing and Rendering rfc8222
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 [EMAIL PROTECTED] Economics Department, University of Utah (801) 581 7797 (my office) 1645 Campus Center Dr., Rm 308 (801) 581 7481 (econ office) Salt Lake CityUT 84112-9300 (801) 585 5649 (FAX) ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
[Mailman-Developers] LoopError vs. Approve.py
(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 LeeI.T. Service : : Senior Systems ProgrammerComputer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham DH1 3LE: : Phone: +44 191 334 2752 U.K. : ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Parsing and Rendering rfc8222
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 [EMAIL PROTECTED] Red Hat Inc. ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Turning off dynamic JavaScript
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 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Turning off dynamic JavaScript
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 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Turning off dynamic JavaScript
On 7/5/06 11:26 AM, emf [EMAIL PROTECTED] 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@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] LoopError vs. Approve.py
-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- ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Turning off dynamic JavaScript
--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/ ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
[Mailman-Developers] What I did on my summer vacation
-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- ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
[Mailman-Developers] Accessible DOM manipulations
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 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Parsing and Rendering rfc2822
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 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Parsing and Rendering rfc2822
-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 LF 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- ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Parsing and Rendering rfc8222
-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- ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Parsing and Rendering rfc8222
-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- ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Parsing and Rendering rfc8222
-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- ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
[Mailman-Developers] Turning off dynamic JavaScript
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 [EMAIL PROTECTED] 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 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
[Mailman-Developers] Fwd: Re: Turning off dynamic JavaScript
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, [EMAIL PROTECTED] 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 http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@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=showfile=faq01.027.htp __ NOD32 1.1617 (20060623) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Turning off dynamic JavaScript
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@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=showfile=faq01.027.htp __ NOD32 1.1617 (20060623) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Parsing and Rendering rfc8222
On 7/5/06 4:30 PM, Barry Warsaw [EMAIL PROTECTED] 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 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
[Mailman-Developers] Strange words that don't exists in Wikipedia and MonoBook.tpl the output continue to be identical ?
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 ?
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Strange words that don't exists in Wikipediaand MonoBook.tpl the output continue to be identical ?
I MADE AN ERROR WITH ANOTHER MAILING LIST I have posted the message in mailman-developers@python.org and not in [EMAIL PROTECTED] PARDON ME ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
