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
[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
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
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
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
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
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
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
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
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
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
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:
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,
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:
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[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
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
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
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
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
45 matches
Mail list logo
