Barry wrote:
> OTOH, I've used Linux and OSX, and before that NeXT, Solaris and
> various Unixes for (unfortunately, way :) longer than there's been a
> web, and except for the Windows programming I do at work, haven't
> ever used IE for any substantial amount of time.
I've been using Unix and th
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 7, 2006, at 12:50 AM, Mark Sapiro wrote:
> 4) PEP 8 recommends all lower case module names, although consistency
> with existing Mailman module names probably overrides that.
I haven't had time to look at the patch yet, but I've been trying to
David Lee wrote:
>
>Being completely new to both Mailman and python programming (though with
>several years of majordomo and perl behind me!) I thought I'd check that
>I'm on the right lines. Attached is a shot at a "UserAuth.py" module(?)
>to maintain the passwords, with ideas borrowed from "Util
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 7, 2006, at 12:08 AM, Brad Knowles wrote:
> One thing that really concerns me is excessive complexity in the user
> interface. As a MacOS X/Safari user, I've found so damn bloody
> many web
> sites that are totally hosed for me, regardless o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 6, 2006, at 10:16 PM, Bob [EMAIL PROTECTED] wrote:
> One thing that I find very disappointing is to (google|yahoo\fav
> search) a solution to a problem,
> only to find that the message that looks promising is in an archive
> that has been e
Ethan quoted Bryan Carbonnell:
>> For me it's nothing specific. It's more philosophical. I am a very
>> minimalist when it comes to the 'net. Plain text e-mail and no
>> scripting or embeded audio/video on web pages.
>
> I can appreciate that philosophy, to some extent. So you always surf
> with J
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 6, 2006, at 2:09 PM, John Dennis wrote:
>> As I understand it, any user agent is free to throw on any X-header
>> their little heart desires, so that strikes me as a lack of a-priori
>> knowledge.
>
> No problem, silently ignore unknown fields.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 6, 2006, at 1:56 PM, Brad Knowles wrote:
> Barry said:
>
>> We should certainly do everything we can to make sure that Richard's
>> ht:dig solution is nearly trivial to integrate, but I'm not sure we
>> should distribute it with Mailman.
>
> So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 6, 2006, at 1:29 PM, emf wrote:
> Another approach would be something like:
>
> To [EMAIL PROTECTED]
> ...
> X-Foo blarg
>
> I'm not against that.
It might sense to use RFC 2822 terminology:
To[EMAIL PROTECTED]
...
???
I think you do proba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry to go on-list about this but I can't reply to John Dennis;
Redhat's mail server is blocking me. John if you have an alternative
email address, contact me off-list and I'll forward you the rejection
message.
- -Barry
-BEGIN PGP SIGNAT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 6, 2006, at 2:33 PM, John Dennis wrote:
> My apologies, I have yet to read Barry's SQL work so perhaps the issue
> of how a user is defined has been greatly enhanced over the current
> 2.1
> model.
It hasn't and frankly I don't see that as a
Barry wrote:
> I'm sure a lot of that comes from me, inspired by early experience
> and my own general paranoid dinosaurism. OTOH, I remember Guido
> telling me a few years ago that I might as well give up on that one,
> and so I have -- mostly. That's why I love NoScript so much :).
No, you're
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 6, 2006, at 2:11 PM, David Lee wrote:
> I've had to devise my own (very simple!) scheme for creating and
> managing
> a user database of email-address and password. (In our context, at
> present, this could just about be managed by Mailman a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 5, 2006, at 5:27 PM, Arne Schwabe wrote:
> Barry Warsaw schrieb:
>> If you want to get a taste of the things I'm going to check in soon,
>> please see:
>>
>> http://wiki.list.org/x/vg
>
> That page does not seem to public accessable. It asks me
Bryan Carbonnell wrote:
> For me it's nothing specific. It's more philosophical. I am a very
> minimalist when it comes to the 'net. Plain text e-mail and no
> scripting or embeded audio/video on web pages.
I can appreciate that philosophy, to some extent. So you always surf
with JavaScript turn
Some good discussion going on here regarding archives. Just thought I'd chime
in on the pipermail
thing.
One thing that I find very disappointing is to (google|yahoo\fav search) a
solution to a problem,
only to find that the message that looks promising is in an archive that has
been either nu
John Dennis wrote:
> I wasn't referring to
> just the email archiving, but rather all the pages mailman generates.
Oh! well, they'll all be xhtml, so that should let you throw down some
xslt action.
> I saw a subsequent post from you in which you said "xslt is evil" so I
> guess you're probably
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 6, 2006, at 1:19 PM, emf wrote:
> Barry et. al.:
>
> Barry, I've read about your SQLAlchemy work and look forward to seeing
> that checkin ;)
Heh, if only it worked. I've got a message sitting in my queue from
their mailing list so I'm goin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 6, 2006, at 4:45 PM, emf wrote:
> On somewhat of a side note, I have heard a certain amount of antipathy
> towards JavaScript in this forum. I know it was unpleasant in the late
> '90s, but it is much better and more cross-browser these days.
On 7/6/06, emf <[EMAIL PROTECTED]> wrote:
> Bryan Carbonnell wrote:
>
> > I have to agree with Brad on this.
> >
> > An option may be to give the site admin the ability to turn the JS
> > on/off site wide with a mm_cfg.py variable.
>
> I'm a little reluctant to add another bit flip to mm_cfg when y
On Thu, 2006-07-06 at 18:07 -0400, emf wrote:
> John Dennis wrote:
>
> > Speaking of stylesheets and customized UI, are you planning on having
> > the core mailman code generate xml, which then is transformed with xslt?
>
> This would be nice. My immediate target is getting email into an
> Eleme
John Dennis wrote:
> Speaking of stylesheets and customized UI, are you planning on having
> the core mailman code generate xml, which then is transformed with xslt?
This would be nice. My immediate target is getting email into an
ElementTree, and then displaying it using some combination of pyt
Brad Knowles wrote:
>>> Archiving and MLM (Mailing List Manager) functionality can be
>>> orthogonal to each other.
>> I can imagine - but have never used - a mailing list where access to
>> past emails is 'orthogonal' to the use of the mailing list.
>
> Majordomo, older versions of Mailman, as j
John Dennis wrote:
> Perhaps the right model is a hierarchical
> resolution of attributes, e.g.
In order to provide administrative control over what UI elements are
implemented I'm already implementing a tool that will provide control
over which elements are active on a Server/Site/List/User l
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
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
On 7/6/06, Laura Carlson <[EMAIL PROTECTED]> wrote:
> > An option may be to give the site admin the ability to turn the JS
> > on/off site wide with a mm_cfg.py variable.
>
> Default set to off?
That'd be my preference.
--
Bryan Carbonnell - [EMAIL PROTECTED]
Life's journey is not to arrive at
Ethan wrote:
>>> One example is keeping extraneous text hidden until it is
>>> selected; I imagine that someone using a screen reader/portable
>>> device would appreciate being able to read a "overview" page
>>> variant and then being able to expand as necessary.
An overview at the top of a page
On Thu, 6 Jul 2006, John Dennis wrote:
> > On Thu, 6 Jul 2006, emf wrote:
> >
> > > Barry, I've read about your SQLAlchemy work and look forward to seeing
> > > that checkin ;)
> > >
> > > 1.) I have to have a concept of user to really improve the user
> > > interface. ...
>
> My apologies, I have
On Thu, 2006-07-06 at 14:17 -0400, John Dennis wrote:
> ... don't forget for those folks who dislike
> pipermail one can with minimal effort use an external archiver.
Oh, and I should have added that one of the beefs with using an external
archiver is the disjoint UI between mailman and the archi
> On Thu, 6 Jul 2006, emf wrote:
>
> > Barry, I've read about your SQLAlchemy work and look forward to seeing
> > that checkin ;)
> >
> > 1.) I have to have a concept of user to really improve the user
> > interface. ...
My apologies, I have yet to read Barry's SQL work so perhaps the issue
of ho
On Thu, 2006-07-06 at 13:45 -0400, Brad Knowles wrote:
> [ snip discussion of fixing pipermail and alternate archivers ]
> But this is a pretty big undertaking.
I'm 100% with Brad on this, this is a huge chunk of work, probably a
project in its own regard. Would you really finish this during yo
On Thu, 6 Jul 2006, emf wrote:
> Barry et. al.:
>
> Barry, I've read about your SQLAlchemy work and look forward to seeing
> that checkin ;)
>
> Here's my situation:
>
> 1.) I have to have a concept of user to really improve the user
> interface. Many things become easier, but there are things I c
On Thu, 2006-07-06 at 13:29 -0400, emf wrote:
Pardon my top post, these are all good points Ethan, it's clear you've
given it careful thought.
> Another approach would be something like:
> To [EMAIL PROTECTED]
Yeah, that would work too, but it's a little awkward, I like your
original idea better
Barry said:
> We should certainly do everything we can to make sure that Richard's
> ht:dig solution is nearly trivial to integrate, but I'm not sure we
> should distribute it with Mailman.
Sorry, I guess I wasn't clear -- I just meant for him to look at both
Python and non-Python solutions, befo
On 7/6/06, Brad Knowles <[EMAIL PROTECTED]> wrote:
> Ethan wrote:
>
> > One example is keeping extraneous text hidden until it is selected; I
> > imagine that someone using a screen reader/portable device would
> > appreciate being able to read a "overview" page variant and then being
> > able to e
Ethan quoted John Dennis:
>> It's not at all clear to me that mailman should be responsible for
>> archiving.
>
> While I am somewhat in agreement, the current situation is that
> archiving comes bundled with mailman and represents a significant
> weakness in its current web UI. Not doing anything
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 6, 2006, at 1:14 PM, Max Bowsher wrote:
> Barry Warsaw wrote:
>> If you want to get a taste of the things I'm going to check in soon,
>> please see:
>>
>> http://wiki.list.org/x/vg
>
>
> Seems to require you to register and log in merely to vie
Barry Warsaw wrote:
> If you want to get a taste of the things I'm going to check in soon,
> please see:
>
> http://wiki.list.org/x/vg
Seems to require you to register and log in merely to view it...
shouldn't anonymous viewing be allowed?
Max.
signature.asc
Description: OpenPGP digital sign
Ethan wrote:
> One example is keeping extraneous text hidden until it is selected; I
> imagine that someone using a screen reader/portable device would
> appreciate being able to read a "overview" page variant and then being
> able to expand as necessary.
I would much prefer to do this without Ja
John Dennis wrote:
> O.K. that makes sense, but I guess it boils down to a design choice.
>
> 1) Well defined DTD/Schema, but awkward to use in practice.
Another approach would be something like:
To [EMAIL PROTECTED]
...
X-Foo blarg
I'm not against that.
> 2) Easy to use, but no standardized
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
At 01:54 PM 7/5/2006, John W. Baxter wrote:
>> Does the industry (I almost wrote "do we") know how big a problem
>> this is in practice? That is, what fraction of users of screen
>> readers and other assistive stuff routinely run with JavaScript
>> active?
>>
>> Since the assertion here is "scree
On Thu, 2006-07-06 at 17:24 +0100, Ian Eiloart wrote:
>
> --On 6 July 2006 11:30:08 -0400 John Dennis <[EMAIL PROTECTED]> wrote:
>
> > I'm not sure I understand what the purpose is in treating the extended
> > fields differently, it seems like it would overly complicate the xml
> > navigation wit
Hi,
I was just discussing Mailman features with our user-support person. One
idea we had (not directly related to the web interface) is a test address
for every list.
The purpose is to test a list setup without spamming everyone. So, if we
had a list [EMAIL PROTECTED], it would be nice to be a
--On 6 July 2006 11:30:08 -0400 John Dennis <[EMAIL PROTECTED]> wrote:
> I'm not sure I understand what the purpose is in treating the extended
> fields differently, it seems like it would overly complicate the xml
> navigation without any clear advantage. Anyone who is interested in the
> value
On Thu, 2006-07-06 at 10:55 -0400, emf wrote:
> Hans G. Ehrbar wrote:
> > If mailman would be able to write an xml representation of
> > each message to a separate file, that would be wonderful.
> > Then one would be able to use xlst stylesheets to make
> > custom archives.
>
> I've looked into th
Thank you for the correction, David.
--John
On 7/5/06 5:07 PM, "David Andrews" <[EMAIL PROTECTED]> wrote:
> That assertion is not true, to my knowledge -- and I am a screen reader user.
> Because it does work with a lot of things, and does offer improved
> functionality, it is rare to turn Jav
Hans G. Ehrbar wrote:
> If mailman would be able to write an xml representation of
> each message to a separate file, that would be wonderful.
> Then one would be able to use xlst stylesheets to make
> custom archives.
I've looked into this a bit, and so far have found only a few
schema-like thin
--On Thursday, July 06, 2006 1:30 AM +0200 emf wrote:
> I had indicated in a
> previous post that the mailman interface I am building
> will be fully
> functional without javascript/css;
Excellent, Ethan. Sorry for the confusion.
Thanks for all of your hard work.
All the Best,
Laura
_
--On Thursday, July 06, 2006 1:30 AM +0200 emf wrote:
> I had indicated in a
> previous post that the mailman interface I am building
> will be fully
> functional without javascript/css;
Excellent, Ethan. Sorry for the confusion.
Thanks for all of your hard work.
All the Best,
Laura
_
52 matches
Mail list logo
