[Mailman-developers] Found it! (I have a divergent version of MailMan)

[Ken Manheimer]

On Fri, 1 May 1998, The Dragon De Monsyne wrote:

> On Fri, 1 May 1998, Ken Manheimer wrote:
> 
> > (I'm confused about how working with respect to the ~mailman homedir
> > enables you to have to install's, btw.)
> 
> 	I have two mailman users, 'mailman' & 'mm', and separate base
> urls, etc. The neccesary magic to make it all work is this line at the
> begining of the scripts:

Ah, a separate user.  Cool.

> sys.path.append(os.path.join(pwd.getpwuid(os.geteuid())[5],
> 		"mailman","modules")) 
> 
> A bit ugly, but it works.( a package would be more elegant, of course. )

Not bad.  If you look at mailman/cgi/private, andrew kuchling did
something along the same lines.  You implemented something more refined
by getting the user id of calling process. 

Using relative paths wherever possible (using packages for the modules
and relative paths for scripts and wrapper executables) is my favorite
prospect.

> 	Yah. I had a list with it, and they kept getting 
> "prefix Re: prefix Re: prefix ...." I munge the subject before the prefix
> gets put on the outgoing message, so the prefix winds up first. The
> problem with having the Re first, is then filtering dosen't work.  

Not sure what you're saying, but i implemented something here that
leaves the "re" alone, but still filters fine to avoid cascading
prefixes.  Small hack, with no apparent problems and many messages under
the bridge (or something:). 

> > > (major) Changed the way user data is stored (still tying up loose ends on
> > > 	this)
> > > 	Created a User class. User data is no longer stored in the
> > > [...]
> > If you're saying what i think you're saying, this is a real biggie, one

> Yup. I may be tweaking the code a bit on this before diving in in earnest
> [...]
> this: I wanted to have hierarchy of objects here. You start with a
> Server object that manages all server-wide info. you can get Mailinglist

Sounds like this will also feed in well to john's planned creation of a
threaded persistent server mode. 

It also sounds like it'll provide a good basis for another feature i
really want - user profiles. 

The simplest use of these profiles would be to contain a user's
preferred password, which a user shares across lists on a site.  They'd
just have to change that password, rather than going through the process
for every list to which they subscribe.  (List-specific passwords could
still be available, so the user wouldn't *have* to use the same password
for all.) 

Also, delivery address could become a secondary aspect of the user
account, rather than the key by which it is identified.  This way, the
user could change the delivery address without having to unsubscribe and
resubscribe.  (They'd have to go through a confirmation process that
proves they're in charge of the new address, to prevent mischief makers
from subscribing at a valid address and then changing to some arbitrary
other address.)  

And the profile could be used for "incidental" member info, like name,
organization, etc, to provide background for the mailing list community
- etc...

Anyway, it all sounds real good!

ken manheimer
klm@python.org