[Mailman-Developers] Hi! I'll be your intern for the summer :)

Hey, all; I'm ethan fremen, and I've been selected for a WebUI Summer of Code project. I'll keep a running log of my progress at http://wiki.list.org/display/DEV/Summer+of+Code My svn branch is https://svn.sourceforge.net/svnroot/mailman/branches/soc2006-webui ; feel free to check it out as t

Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)

> 1. KISS -- I sometimes have to do list administration and > moderation from my Treo 650, so anything that depends on > graphics, JavaScript, CSS, or anything fancy is really bad > news. Ug, yeah. There's so much cruft stuck in so many places that I'

Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)

Ian Eiloart wrote: >a) arbitrary page headers and footers so I can make it match the rest > of my site. I'll give you this *and* throw in "arbitrary page-chunks you can plop right into your page", in case you just want to expose, say, the moderator interface. >b) site-wide masking of f

Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)

Laura Carlson wrote: > I mentioned this about a year ago [1], it would be great if the Mailman > templates, like the general list information page and the user specific > options page, were accessible and standards compliant. Thanks very much for your feedback, Laura! I am something of a standa

Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)

Ian Eiloart wrote: > How about this for extra: > > 1) Display a list of ALL members - just their names and addresses. > 2) Delete ALL the list members with one click - OK, and maybe a confirm > dialog! Hm. This comes slightly in opposition to the desire to have a more user-centered mailman int

Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)

[EMAIL PROTECTED] wrote: > I'm not aware of anything about mod_python that would make your work > not also support FastCGI and SCGI. Am I correct? I don't know for certain; I was planning on at least trying to implement RSS feeds as an output filter, which as far as I know means I'm hooking into

[Mailman-Developers] SoC: status update

http://wiki.list.org/display/DEV/Summer+of+Code Gentlebeings, I have updated the summer of code page above to indicate my current progress and record the synthesis of the opinions I have received so far. Thank you for the excellent feedback you've provided so far; don't be shy about continuing

Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)

Terri Oda wrote: > 1. Integration with look/feel of people's existing websites > > As others have said, the biggest question I get from people is usually > along the lines of "How can I make Mailman fit in to the rest of my > website?" The main thing I'm doing in this regard is building each

[Mailman-Developers] bulk subscriber changes

Ian Eiloart wrote: > Well, for some of our lists it's simply inappropriate for users to set > preferences. OK, I can see this. My query/issue is this: as I understand it, completely re-setting the list membership will also reset mailman's memory of who bounces, etc. So if any of the new membe

Re: [Mailman-Developers] bulk subscriber changes

Ian Eiloart wrote: > Yes, that sounds good. I'd be uploading a list of addresses to be synced > with the current membership. Great! I'll go this route. > Erm, perhaps. It would still be nice to be able to delete all the > members, though. For example, I can bulk subscribe a list of people. If

Re: [Mailman-Developers] Acessibility Testing Tools (was Re: Hi! I'll be your intern for the summer :))

Laura Carlson wrote: > David Andrews already mentioned the demo versions of JAWS and > Window-Eyes [1]. I'll use the firefox jawsy thing and see what I can do past that point once I get windows on this box. > Home Page Reader [3] is also a good tool for web developers and > designers who are

Re: [Mailman-Developers] SoC: status update

Tokio Kikuchi wrote: > Hi Ethan, > > Since you are working on Web Interface, I have an important > suggestion/request on the charset we use. 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 (individ

[Mailman-Developers] ids, javascript, and Forms Acessibility

Laura Carlson wrote: > I would caution against using implicit labels. I think your advice is correct. Here is the conundrum that had me using implicit labels in the first place: a.) All mailman page-elements need to be embeddable into other pages; this means that I can't collide with unknown

[Mailman-Developers] Please Tell Me How You Translate

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 soun

[Mailman-Developers] Turning off dynamic JavaScript

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 re

Re: [Mailman-Developers] Turning off dynamic JavaScript

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 br

Re: [Mailman-Developers] Turning off dynamic JavaScript

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 o

[Mailman-Developers] Parsing and Rendering rfc8222

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 perfo

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

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

[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

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

[Mailman-Developers] email schemas

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 thin

[Mailman-Developers] Users, persistent storage, caches, etc.

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

Re: [Mailman-Developers] email schemas

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 [EMAIL PROTECTED] ... X-Foo blarg I'm not against that. > 2) Easy to use, but no standardized

Re: [Mailman-Developers] Accessible DOM manipulations

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

Re: [Mailman-Developers] Accessible DOM manipulations

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

Re: [Mailman-Developers] Users, persistent storage, caches, etc.

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 l

Re: [Mailman-Developers] Parsing and Rendering rfc2822

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 j

[Mailman-Developers] email schema / XSLT

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 pyt

Re: [Mailman-Developers] email schema / XSLT

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

[Mailman-Developers] The Philosophy of Web Use.

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 turn

Re: [Mailman-Developers] The Philosophy of Web Use.

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

Re: [Mailman-Developers] The Philosophy of Web Use.

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 hel

Re: [Mailman-Developers] The Philosophy of Web Use.

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 cent

[Mailman-Developers] soc2006-webui updated

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 som

Re: [Mailman-Developers] soc2006-webui updated

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 ___

Re: [Mailman-Developers] Integrating Mailman with a single sign-on service

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 o

[Mailman-Developers] Anyone have a pickle / mbox to spare?

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, t

[Mailman-Developers] Decorators in MailList.py ....

Hallo! I am noticing there are decorators in MailList.py... does that mean I can use them? ~ethan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python

[Mailman-Developers] Bounces, Pickles, Coding Styles Oh My

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 no

[Mailman-Developers] Password reminders "going away" in 2.2

So does this mean I don't have to implement that bit of preferences UI? ~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

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [7989] branches/soc2006-webui

Sorry for all the property changes. SF.net doesn't seem to let me set repository tags. Any chance someone (barry?) can add .pyc to svn:ignore on the server side? Thanks, ~ethan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://m

[Mailman-Developers] development setup?

Gentlebeings, As we enter the end of my SoC internship, I still have a long road to hoe to get to a complete UI for Mailman. That being said, I'm definitely going to continue working with this at least until it makes it into a mainline release, and hopefully longer. Here's my quandary: I need

[Mailman-Developers] Timing, events, runners, oh my

Gentlebeings, The UI would like to use email for a variety of functions, and it would like some event-based code. I was wondering how much of mailman's existing infrastructure I should use. a.) I would like to allow "email login", where a passwordless user receives an email confirmation link.

[Mailman-Developers] SoC Summary

Gentlebeings, A thousand pardons for not delivering a functional UI by the deadline of my SoC project. I have written a summary of my experiences at: http://wiki.list.org/display/DEV/2006/08/20/Summer+of+Code+summary and I assure you that I will continue to work on this project for the foresee

[Mailman-Developers] Security standards?

So as I understand it, mm 2.2 is dropping email reminders of passwords. This has made me think that we'd like more support for 'passwordless' manipulation of the UI. I've come up with a few approaches for this, and I'd like to get feedback as to what would be acceptable. Please keep in mind I'l

[Mailman-Developers] trunk checkins ok?

Gentlebeings, There are things I'd like to change that seem like they'd be best changed on the trunk; the two examples at the moment are list_names() doesn't talk to the config object properly and I found a python implementation of line-wrapping by a number-theory guy that claims to be at leas

Re: [Mailman-Developers] Incoming Queue format

Brad Knowles wrote: > Among other things Maildir creates really hairy long filenames, which > can easily blow the iname/inode caching built into most filesystems I can't find a filesystem that has a filename dependency for inode caching, so I suspect I'm completely misunderstanding this. Could

Re: [Mailman-Developers] Digest queue possibilities

Barry Warsaw wrote: > BTW, what do you think about changing the way we hold messages for > digests? E.g. instead of putting them in an mbox file, where it's > more difficult to skip bad messages, stick them in a queue-like > directory and pull them from there. Any messages that can't be re

Re: [Mailman-Developers] Incoming Queue format

Brad Knowles wrote: > So your assumptions about what kinds of filesystems may or may not be > appropriate are not necessarily going to coincide with the decisions > that other people make, or the kinds of hardware and OS they may be > forced to live with. I don't disagree with this assertion,

Re: [Mailman-Developers] Index Listing of mail lists

[EMAIL PROTECTED] wrote: > > We can't wait to see the code you're going to contribute to do this. ;) > > I wouldn't spend effort on waiting if I were you; I'm thinking in > terms of Mailman 3. I'm trying to modularize the web code now; I'm using something vaguely like a pipeline. At the very

[Mailman-Developers] The one-giant-object approach

Gentlebeings, I'm trying to hook up the object-relational mapper I've worked out to mailman, and I'm encountering an issue I'd appreciate feedback on. Take MailList. Aside from its own namespace, it mixes in 11 other classes, leading to 255 names if you dir(list). Is this large, flat namespace a