[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 preference? It seems to me like it mixes together many bits of functionality that aren't always needed by whatever code needs a 'list'. It seems to me that if things were broken up a little bit they'd be conceptually easier to follow, and it'd be easier to make improvements. While I understand that a unified DB likely won't make it into 2.2, I would like to break out some functionality, and I just wanted to make sure that keeping a flat namespace wasn't a design goal. Thanks, ~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] 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 least, all of the code that applies to sequences should work for lists of users/lists/messages. If you want to play along, check out the soc2006-webui branch :) ~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] 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 read and scrubbed would just be removed. I think this would be a great idea, and something like this will be necessary for the Association of Computing in the Humanities for whom I may be doing some mailman contract work. Aside from the specifics that they want, this approach would allow for much easier implementation of custom digest approaches, like: * send me a digest of only the Topics I care about * similarly, send out Topic-specific digests * let moderators edit digests, minimally selecting what gets included but maybe up to editing posts, reordering their occurence in the digest, providing summaries, etc. None of this is impossible with mbox, but would be easier with maildir/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] 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, nor am I making assumptions about what people get to live with. I observe that there is a very finite amount of Mailman developer-hours to be had, and that the problems you're discussing have been addressed by people who spent far more time on the problem than we have available to us. Furthermore, many MTAs *do* understand Maildir, and most admins do as well; using our own queue-on-disk format means MTAs must access Mailman via LTMP, pipe invocation, or the like, and if there are issues with the queue the administrator likely must learn our queue-on-disk format. Being able to deliver to mailman even if mailman isn't currently running strikes me as a potential win for some configurations. Most of the maildir phenomena you have an issue with wouldn't even arise in the use case under discussion; a mail would enter maildir/new , mailman would suck it out, and that would be that; renaming wouldn't occur and the number of elements in the queue is unlikely to become large enough to pressure filesystem indexing schemes. ~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] 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 you expand on that a bit? -- you could get the same benefit by using a better filename naming/hashing scheme with fewer characters. It also does a lot of excessive synchronous meta-data operations (e.g., creating files, renaming files, etc...), and that can place a heavy load on the underlying filesystem. Maybe; but there are at least two filesystems (XFS, reiserfs) and likely more that handle file renaming/creating really cheaply, and have their own ninja ways of dealing with really large directories that are the product of a rather large amount of coding hours. Maildir has the advantage of being bog standard and readily comprehended. While I'm all in favor of some lmtp delivery mechanism, I don't see why we should continue inventing our own queue-on-disk approach merely to cater to poorly designed filesystems. It seems to me like anyone likely to end up with a huge enough incoming mailman queue to care about Maildir's inefficiencies would also be able to put a sensible filesystem underneath it. ~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
[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 least as filled with fu as the emacs version, which I'd like to substitute for wrap(). Is it ok if I make changes on the trunk? ~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] [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://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] 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 to have several mailman installs 'up and running' - on a I can talk to the pickles level, anyway. How do I get such a beast out of svn? INSTALL points me to an 'admin' directory that isn't in svn. I had thought of just adding svn_dir to my pythonpath, but I need a configuration file, and in general I would like my code to be verbatim what is needed to run it against a production server. Thanks, ~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] 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 foreseeable future, or at least until it makes it into a main-line release. Thank you all for all the help you've been so far; I expect to continue to rely on it as I move closer to something we can actually use. ~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
[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'll allow administrators to require more authentication than I outline below. * Use case A: an email is a member of a mailing list but has never logged into the interface. I was thinking it would be ok in this context to allow a user-agent to approach the interface and provide only the email address to be provisionally authenticated; they would be allowed to manipulate the member's settings. Once they were done doing so, an email would be sent to the address that required clicking on a confirmation link to make the changes active. * Use case B: a user-agent presents an email that has used the interface previously. If the user-agent presents a visitation cookie that was active during the previous manipulation, the user is provisionally authenticated again, and gets a similar confirmation email. If they did *not* have a matching visitation cookie, or present another this-is-really-me token, they would not be allowed to manipulate the interface until they click a email-verification link. * Use case C: Some other code (an upstream process, OpenId server, etc) provides a username for a user. In this case we accept the user as authenticated, and either use our map of username- email addresses for purposes of determining membership or accept an email_addresses list from the WSGI environment or from the remote server/other process. If only the username is provided, the user is given the opportunity to indicate which email addressess should be associated with that username; once they have done so, verification emails are sent to said addresses, and post reply/link activation mailman considers those emails to be associated with that username. Does this stuff sound reasonable? ~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
[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 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['[EMAIL PROTECTED]'] 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 ___ 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] 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.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] 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, 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 ___ 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] 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.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] 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 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. ___ 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] 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 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 ___ 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] 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 ___ 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] The Philosophy of Web Use.
Brad Knowles wrote: I just read the intro to a Slashdot article at http://slashdot.org/articles/06/07/06/1654242.shtml, 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 ___ 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] 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 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 ___ 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] 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: headernameTo/name [EMAIL PROTECTED]/header ... headernameX-Foo/name blarg/header 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 ___ 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] 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
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
___
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:
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 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 ___ 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] 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 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 ___ 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
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=showfile=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 ___ 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] 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 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 ___ 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] 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 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 ___ 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
[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
[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 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 ___ 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
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
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 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 ___ 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
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 ___ 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] 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 looking to try out a speaking browser. I think I can make OS X read pages, too, so I'll poke into that. One of the tools that I have my students use is to test forms is the WAVE. [5] It will spot violations like missing labels, labels not associated with inputs, empty labels, etc. and notify you with icons. [6] Great! I will use that and Cynthia. There's a great little Colour Contrast Analyser Firefox Extension [8] OOh, neat! I heart firefox's extensibility. I already use color-scheme generators (and stay away from shade-changes only), but this will be a help, as I happen to be a boy blessed with a fully functioning X chromosome and have no colour blindness. ~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] 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 (individual) emails with the charset referenced. 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? ~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] 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 id's elsewhere on the page. Not too much of a problem; I can have a Mm- prefix to denote mailman ids. b.) Many form elements will repeat. One example is a user looking at the options for 1 list at a time. Also, a.) means I can't know how many of me (where I'm a form-chunk) a site administrator has imbedded into the page. Of course, talking it out has presented a potential solution; let me know if it seems off. I'm thinking of using Kid to generate pseudo-random numbers for ids. This works great, except when someone wants to use an id selector in CSS or getElementById() in JavaScript. If I do this, I'll have to use class attributes (which happily can contain many values) to disambiguate form elements for JavaScript, and JavaScript will have to add/remove class attributes to change display for CSS. This is fine save that View Source becomes more opaque for someone who just knows CSS and HTML. - Keep the number of accesskeys to a minimum. The only accesskeys I want to provide would be for speeding moderation. I'm filing the rest of your advice in the wiki, so that I may keep it in mind. TABINDEX having a sensible natural order to start with, meets WCAG requirements for HTML documents. I think this is a good idea, but I'm not going to control the global order of the pages the controls sit in, which is probably an argument for forgoing tabindex all together. If the tabindex attribute is not assigned to all fields, JAWS first moves through the items with a tabindex assigned, then moves through the other form fields and links in the order they appear on the page. This is interesting. I have some global controls I was going to have sit on top of the content, and float it right. Now it sounds like I should put the global controls after the content, and use absolute positioning to put them on the right. Constrains the page-flow a bit more than I would like, but it is probably worth it. On the other hand, the first form element in the global control set is turn global controls on/off so perhaps that won't be that much of a bother. ~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] 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 piece of functionality, down to individual options, as separate pages/page snippets that will work if embedded into another page. If the user has JavaScript and a browser that supports XMLHttpRequest, the form submissions will happen asynchronously and feedback will occur within the site's page; if they do not they will go to a mailman-specific page that can still be styled by the site administrator. Some of the, you aren't going to have much control over (Top of list: why can't we just have users with one password for mailman and everything else?) While I can't take this on this summer, I am building as if mailman has a concept of a user and - if Barry doesn't come back from vacation with a Super Happy Report with regards to SQLAlchemy - writing glue code to make the UI behave as if there were a concept of a user. Said glue code should be able to handle the site providing user/pass details, as it will already be looping through the list(s) collecting user/pass details. There are some icky complications with this- if the site doesn't notify the glue code a user's pass has changed, it won't be for mailman, and if the code gets halted before it updates all the passwords for a user the user might end up with some lists failing to allow auth. It comes down to me not being able to figure out how to make a user interface for software with no real concept of a user, so I will do the lifting required to at least generate the appearance of such. but things like making the interface all css friendly (is the plan for it to be all xhtml-compliant?) Unless I am forced to go transitional by browser vagarities, all my pages will be xhtml strict. and providing configurable headers and footers will make a pretty huge difference right there. The headers and footers are going to be window dressing*. Every single other component will be embeddable from any program capable of fetching an url using basic auth. * they will of course be stylish and customizable, but from what I've seen, the First Thing every site administrator wants to do is rip chunks out of the UI and embed them into their pages. 2. Simplified (possibly customizable?) interface as an option I'm using standard elements and CSS's ability to style child nodes as much as possible; this means that interface elements should take on the site's styles automagically, with the possible requirement of adding selectors for those sub-elements they hadn't styled themselves. (It is making me wish I didn't have to specify *which* header level I meant, but enh.) I'd also like to see it possible to make a page that contains a simplified version of the interface. My thought is I don't know in advance which options are most important to which users. Therefore I'm working on a page that (ala google's customized home page) lets you drag/drop option elements around (or reorder them via form submissions, if you're without javascript). I'm also making a config page for a site/domain/list administrator that will allow the specification of which options should be available and in what order. 3. Organization I dislike the way the list admin interface is currently organized. a-bloody-men to that. The first thing I've done is move the wordy and visually cluttering help text and its confusing sub-pages with more help into pop up / submit-form-to-display elements. The other half of that is as above; I don't think I know the Right Places, so I'll defer to the site administrator as to which options should be presented in which order. 4. Wishful thinking For example, I've yet to have anyone guess what an umbrella list was and what it's for unless they were already familiar with mailing lists... The help thing might address this issue, but the other side of this point is that I will try to provide a task centric approach; the current interface is noun heavy and verb light. I'm going to try to offer a so you want to... interface option so that people can figure out they want an umbrella list, for example. 5. Archives? Are you going to get a chance to touch the archives? A lot of the same things apply for templating there, and people always want that same look/feel. Yes. Basically my approach is punting on pre-rendering archives entirely in favor of dynamically rendering* the .mbox / rfc8222 files as xhtml/RSS/atom. This will avoid the re-archiving your 10 years of archives totally horks your box situation I encountered once, a while ago. Additionally it will eliminate the maddening index-by-artificial-date-segment stuff that currently amputates threads. Finally, the private/public archives have
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 standards fanatic; all the pages I've re-written so far have made heavy use of label (although I use the implicit label where possible), fieldset, legend, thead tbody and the title attribute to provide as much support for assistive technologies and alternative renderings as I can. Once I have a clear idea what form elements will be where, I am also going to add tabindex and accesskey attributes to the form elements. Because all the mailman templates are a hideous mismatch of CAPS TAGS and lcase tags and all sort of tag-soupishness, I'm re-doing them all as xhtml strict. Right now the xhmtml templates are all checked in at: https://svn.sourceforge.net/svnroot/mailman/branches/soc2006-webui/Mailman/Gui/templates/kid/ I'm thinking I'm going to move the kid thing up to templates, move the existing templates back to their original location. There are too many advantages for me in switching over to mod_python, so for the moment my backward compatibility stance is to leave the old cgi-bin stuff as is and just focus on implementing everything using mod_python. When form fields are not labeled explicitly, screen readers will skip over the text on your form when users try to enter data. What's also lame is the way that the user can't click on the label to toggle/enter the input item. Thanks for all the references. If you know of a way that I can actually test JAWS or another screen reader, I would be grateful for the pointer. ~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] 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 interface; what happens if a user changes their preferences and you re-build the entire list? An associated problem is what happens to users that are subbed to 1 list? I recognize this may not be an issue in your specific case, I just think that issues like these will be more of a deal when we don't keep members in per-list silos. Perhaps something that might be more appropriate would be a member differ, wherein you upload a list of email addresses, and it shows you the list of emails that were on the list but aren't now, and those that would be added, and gives you the option to either accept all the changes or selectively modify them. When you say you'd like these people to be able to take advantage of other mailman features, which features do you mean? ~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] 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 Apache's request stack at a level FastCGI and SCGI don't touch. I suspect there is a way to wrap things so that they'll work as a fastcgi/scgi/cgi, but I don't know that I'm going there. ~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
[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, either here or on the wiki. ~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] 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've just started over writing (x)html templates. I will be using CSS mostly so that underneath the pages can be Very Simple; I've got a Palm TX and table pages can be brutal. Additionally, I fully intend to have a CSS file just for mobile devices. I will also be using JavaScript to add responsiveness to the UI for traditional browsers, but I swear on a stack of comic books that It Shall Degrade Gracefully. Stick to a pure text-only UI as much as possible, Please forgive my insouciance on this point, but I believe one of the weaknesses of the current interface is that it provides no visual cues as to what is important/relevant. I will be using icons to draw the user's eye to relevant details, but I have no intention of gobbling up screen space for bling or committing similar crimes like using image-only links; the interface will be fully functional and aesthetically reasonable with images turned completely off. and try doing some actual tests with various PDAs and phones, as well as all common browsers (including Safari) on all common desktop platforms (including MacOS X). Well, I've got me a testing lab right here! I'm only slightly kidding. Aside from the aforementioned TX, I have an intel mac, so I plan on installing Windows soon so I can see how things work on that end. I'm also going to make sure it's fine in links or lynx. I would hate to see all the current WebUI code get thrown out and replaced with a Web2.0 AJAX/.NET framework. I will be using some XMLHTTPRequest action, but only to allow partial-form-submission, and it will degrade to submit the whole page gracefully. 2. Functionality 3. Completeness I'm not committed to doing much with these problems in this project, but I assure you it is my desire as well; I'm hoping to get us closer to the day where there is One Holy UI that works identically across web/email/cli. I'm not sure you fully understand how important. Or how difficult. ;) Thanks! happily I feel like I'm making quite a bit of progress, so I think we might just get something viable out of this. ~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] 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 features that we don't allow by policy. There's already some of this. No feature shall be visible if it doesn't or shouldn't function. Gotcha. c) templates for lists. We have four or five basic list styles (announce/discussion with open/closed membership and umbrella lists). When we create a list, I'd like to be able to specify there and then which style to use. Without getting too far into file management, I hope to have something beyond three links; have fun. Not sure I can necessarily address the configuration issue. d) When creating an list, I'd like to be able to choose an umbrella for it to live under, and have it inherit privacy settings from that list. This is great; I'm not sure I can do all that without writing a fair amount of under-the-UI code. ~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
[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 the inclination strikes you. I'm especially interested in getting any feedback, either on the wiki or here, about any and all WebUI - or UI in general - ideas in people's heads. While the SoC project is fairly constrained, I want to at least make the future easier. ~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
