wwwthreads, a web-based threaded message board software, formerly released under the GPL, is now being released under a non-free license by the original author. I'm the administrator of wwwthreads for a user community, and we've decided to stick with free software. I suggested to the GNU project that I fork the code and work on extending and improving the capabilies of wwwthreads with the aim of inclusion in GNU. After a bit of discussion with RMS, I'm thinking that perhaps the best thing to do is to work on GNU Mailman to make it capable of doing what wwwthreads does. Many of the extensions I was planning for wwwthreads (for example, integration with email and optionalization of the web interface) are already done in Mailman, and I think that maybe Mailman could benefit from some of the additional functionality I am proposing. Besides which, I'd really like to be able to deal with all of my email in one place, rather than having to zoom off to some web site for a portion of it. I think a lot of web-based-forum users feel the same way.
So I'm writing this email to find out what you think -- is this possible? Is it a good idea?
My current minimum list of features needed to make GNU Mailman useable as a replacement for wwwthreads (with the web-based part fully optional) is as follows:
- web logins for user accounts
- user option to not actually receive mail from lists (for those who want to read lists purely on the web)
- web interface for posting to mailing lists
- web interface for administrator and moderator functions
- web appearance configurability on both an administrator and user level
- program to convert wwwthreads databases to Mailman configurations
Of course, further features would follow those, based on what users say when they've switched from other forum software. I expect that the web frontend would benefit greatly.
Your comments are appriciated.
-Steven
Steven,
Yes, I like the idea. Some comments:
"user option to not actually receive mail from lists"... for lists with archiving, you can already just go and read the archive. I know a lot of people who do this on real lists. You'd just have to change the link to say, "visit the list in forum format" or something like that.
It does sound like Mailman meets many of your requirements already, but not all of them.
I'd love to see this stuff get included. Please do work on it.
John
On Wed, Jul 28, 1999 at 01:18:04AM -0500, Steven Hazel wrote:
wwwthreads, a web-based threaded message board software, formerly released under the GPL, is now being released under a non-free license by the original author. I'm the administrator of wwwthreads for a user community, and we've decided to stick with free software. I suggested to the GNU project that I fork the code and work on extending and improving the capabilies of wwwthreads with the aim of inclusion in GNU. After a bit of discussion with RMS, I'm thinking that perhaps the best thing to do is to work on GNU Mailman to make it capable of doing what wwwthreads does. Many of the extensions I was planning for wwwthreads (for example, integration with email and optionalization of the web interface) are already done in Mailman, and I think that maybe Mailman could benefit from some of the additional functionality I am proposing. Besides which, I'd really like to be able to deal with all of my email in one place, rather than having to zoom off to some web site for a portion of it. I think a lot of web-based-forum users feel the same way.
So I'm writing this email to find out what you think -- is this possible? Is it a good idea?
My current minimum list of features needed to make GNU Mailman useable as a replacement for wwwthreads (with the web-based part fully optional) is as follows:
- web logins for user accounts
- user option to not actually receive mail from lists (for those who want to read lists purely on the web)
- web interface for posting to mailing lists
- web interface for administrator and moderator functions
- web appearance configurability on both an administrator and user level
- program to convert wwwthreads databases to Mailman configurations
Of course, further features would follow those, based on what users say when they've switched from other forum software. I expect that the web frontend would benefit greatly.
Your comments are appriciated.
-Steven
Mailman-Developers maillist - Mailman-Developers@python.org http://www.python.org/mailman/listinfo/mailman-developers
"user option to not actually receive mail from lists"... for lists with archiving, you can already just go and read the archive. I know a lot of people who do this on real lists. You'd just have to change the link to say, "visit the list in forum format" or something like that.
Well, I was thinking that it might be a good idea to have some sort of user account system. This is a functionality which might be objectionable in a mailing list manager, but I'm not sure, since it would have some benefits as well. The idea is that rather than simply subscribing to a mailing list, users would create an account -- complete with username and password -- with Mailman. Perhaps the accounts should be per-list or perhaps a single account could subscribe to a set of lists. The account would include information about one or more addresses to which mail should be sent. At that point, for the ordinary mailing list user, everything is the same. For users who want to make exclusive use of the web interface, though, their username and password would be required at least to post under their username and maybe sometimes for read access (for private lists).
One possibility this opens up is that posts could (optionally, of course) be listed under usernames for those who want anonymity, or with usernames as well as email addresses. One nice thing about that is that if someone has a subscription to a mailing list and switches email addresses, they can just tell Mailman that the new address belongs to them, and posts from that address could be recognized and given their username. From there, things like prefered email addresses for replies to posts regardless of the origin of the post are possible, which would sometimes be nice. I know I'd like to be able to post to certain mailing lists from my work email account and have replies uniformly show up at my regular email address.
I'm wondering what your take on user accounts will be. It's important functionality for a web-based forum, but seems sort of tangental to mailing list management, though it does have some advantages. Perhaps they should be optional, or perhaps they don't belong in a mailing list manager at all and should be handled in a wrapper of some sort. My thought is that they should be optional, and turning them on could also turn on a great deal of web-based funtionality.
-Steven
"SH" == Steven Hazel <cherub@azrael.dyn.cheapnet.net> writes:
SH> I'm wondering what your take on user accounts will be. It's
SH> important functionality for a web-based forum, but seems sort
SH> of tangental to mailing list management, though it does have
SH> some advantages. Perhaps they should be optional, or perhaps
SH> they don't belong in a mailing list manager at all and should
SH> be handled in a wrapper of some sort. My thought is that they
SH> should be optional, and turning them on could also turn on a
SH> great deal of web-based funtionality.I actually believe user accounts are essential, but perhaps that's because of my unique relationship with the python.org lists. I agree with everything you've said.
The biggest problem that I have is remembering all the dang passwords, both user and admin passwords, that I have to use every day. So I would go one step further; I would let the site administrator designate which user accounts can have admin privileges for which lists, so they'd only have to remember one password to administer any list of theirs.
Users should also be able to manage all their lists on one screen. Say they're going on vacation. One button could allow them to disable all their accounts on the site, and another would enable them upon their return.
It's interesting that user accounts are so important for message boarding (a feature that I think would be cool to add to Mailman), because I've been seriously considering this to better support existing functionality. The question in my mind is whether to homebrew all this support, or to leverage off of Zope, which I think already has much of this functionality.
-Barry
From: Barry A. Warsaw
they'd only have to remember one password to administer any list of theirs. Users should also be able to manage all their lists on one screen. Say they're going on vacation. One button could allow them to disable all their accounts on the site, and another would enable them upon their return.
That would be FANTASTIC! I run a bunch of email lists for members of an organization. Each person is on several lists. It would be great if they could just have one screen which could change their preferences for all of the lists they are on. Even to change the email address that the lists send to, and to specify alternate email addresses that they might be sending from (home and work, for instance). They should also, however, still be able to set separate preferences for each list.
What would be great also, if it is set up this way, is to have a SITE ADMIN account, so that the person who runs mailman can have one password to be able to get into anything. On my sight, for instance, I have a lot of mailing lists for which other people are disignated as the administrators. Well, what happens when one of the admins forgets his password to one of the lists? It would be great if I, as the SITE admin, had an overall password which would allow me to go into any of the lists to fix them if the admins don't know how.
--Dan
Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html
On Thu, 29 Jul 1999, Dan Delaney wrote:
What would be great also, if it is set up this way, is to have a SITE ADMIN account, so that the person who runs mailman can have one password to be able to get into anything. On my sight, for instance, I have a lot of mailing lists for which other people are disignated as the administrators. Well, what happens when one of the admins forgets his password to one of the lists? It would be great if I, as the SITE admin, had an overall password which would allow me to go into any of the lists to fix them if the admins don't know how.
Err, isn't this already implimented? Try using your site admin passwd to get into list admin pages.
-- Paul Hebble <hebble@ncsa.uiuc.edu>
-----Original Message----- From: Paul Hebble [mailto:hebble@ncsa.uiuc.edu] Err, isn't this already implimented? Try using your site admin passwd to get into list admin pages.
Hmmm. Maybe so. I don't remember there being an overall site admin password. If so, kindly disregard that last paragraph ;=)
--Dan
Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html
The biggest problem that I have is remembering all the dang passwords, both user and admin passwords, that I have to use every day. So I would go one step further; I would let the site administrator designate which user accounts can have admin privileges for which lists, so they'd only have to remember one password to administer any list of theirs.
User accounts are a great idea, but I would like to suggest that it be done so that websites that _already have_ user accounts can integrate mailman easily. Sites with accounts are popping up like mushrooms after the rain :) and it would be awesome if mailman had an interface that allowed them to "wrap" mailman in their existing setup.
Of course, my motivation for this request is entirely selfish :-) To make this more concrete, this is the kind of stuff I do now to make mailman appear to be an integrated part of an existing site with user accounts:
- Manufacture a password
- Generate a query string with the password
- Call apache via http and get the headers
- Extract the cookie
- Generate another query string with the user data
- Call apache back with the cookie and the query string
- Get the HTML back and strip out everything but the body
- Munge the body to change URLs.
- Plonk what's left into my own auto-generated HTML and send it back to the browser.
Amazingly enough, this actually works. The reason for doing it this way was so I didn't have to modify MailMan (apart from about ten lines commented out). And of course I don't want users who are already logged in to enter any passwords or accept any more cookies.
Anyway, if this sounds like it's worth at least discussing I am more than happy to help figure out how to go about it and volunteer to contribute a PHP script as an example of MailMan integration (the rest of my site is written in PHP).
Thanks!
JohnR
From: John Reekie
I would like to suggest that it be done so that websites that _already have_ user accounts can integrate mailman easily. I don't want users who are already logged in to enter any passwords or accept any more cookies.
I'm in the same boat as John on this one. Consider an Intranet situation. The user has already logged into an Intranet on which he is subscribed to several mailing lists. He should not have to enter another password to configure his lists, he should just be able to click on a link and do it. Purhaps a good way to facilitate this would be to publish a clear specification for how all of the data is stored in the config.db files for lists so that if you already have an Intranet application set up you can just add in a little code to change the Mailman list data yourself. For instance, I already have a screen which allows the Intranet users to changes their password and personal information, including their email address. It'd be great if, when they change their email address, I could just add code into my PHP program which would automatically change their email address on all of the lists to which they are subscribed. --Dan
Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html
"DD" == Dan Delaney <Dionysos@Dionysia.org> writes:
DD> Purhaps a good way to facilitate this would be to publish a
DD> clear specification for how all of the data is stored in the
DD> config.db files for lists so that if you already have an
DD> Intranet application set up you can just add in a little code
DD> to change the Mailman list data yourself.This wouldn't be hard to do, and you might not even need to know the format for the config.db file. You could probably write a small script (using bin/sync_members, etc.) that does the modification for you. In fact, I wrote sync_members to make it easy to synchronize PSA member addresses with our external database. Writing a script for hacking a user's password wouldn't be hard.
-Barry
"JR" == John Reekie <johnr@eecs.berkeley.edu> writes:
JR> User accounts are a great idea, but I would like to suggest
JR> that it be done so that websites that _already have_ user
JR> accounts can integrate mailman easily. Sites with accounts are
JR> popping up like mushrooms after the rain :) and it would be
JR> awesome if mailman had an interface that allowed them to
JR> "wrap" mailman in their existing setup.So it sounds like there are a couple of issues here. One is making Mailman's web interface customizable so that you can make it look like it's an integrated part of the site. It sounds like you go to a lot of work to make this happen. I have some thoughts on this based on the ht2html scripts[1] I wrote, but I'm not sure if they're general or flexible enough. Then again, maybe using style sheets would get us close enough.
Second, it sounds like you want to perhaps have a Mailman hook for authenticating users. Would it be enough to design an API that Mailman would call, given an email address (future: login name) and a password, and ask if they matched? This way, you could write a little Python glue code to consult any password database available.
-Barry
participants (6)
-
Barry A. Warsaw -
Dan Delaney -
John Reekie -
John Viega -
Paul Hebble -
Steven Hazel