Mailman 3 August 1999 - Mailman-Developers

RE: [Mailman-Developers] An NT Mailman version
by Tom Funk 09 Aug '99

09 Aug '99

On Sun, 8 Aug 1999, I (Tom Funk) wrote the following: >> One last thing: is there a CVS tree in place for the Mailman source? Please disregard this question. I found the CVS tree at Python.org. -=< tom >=-

1 0

Re: [Mailman-Developers] An NT Mailman version
by Harald Meland 09 Aug '99

09 Aug '99

[Tom Funk] > Is the locking and forking code only the archiving parts of the code? No. > Or is it spread throughout the source? Yes. "grep -w" the source for (at least) "fork" and "posixfile" to get a quick overview of exactly where. > Has anyone considered porting the forking code to Python threads? The only time I can recall having heard of python threads, was when someone said that using threaded python should be _optional_ even if Mailman started supporting this. I think this was in relation to a discussion of whether Mailman should implement it's own listening SMTP server or aim to interface (i.e. use alias files) for all kinds of other MTAs. I don't know if anything at all came of the discussion, but the general scepticism towards trusting a threaded python implementation probably hasn't quite disappeared yet. > I've not worked with them, but the impression I get is that for the > O/S's that support them, they tend to be pretty non-os-specific. > 'Course I may be wrong on this.... I wouldn't know, as I'm not a python guru by far. > I'd consider working on an NT port. I think that would be nice (even though for my own uses it doesn't matter) -- but I know nothing about cross-platform python and what kind of code hoops such a port would make Mailman. > It's a *great* way to learn all kinds of things about a software > package - and the implementation language. That's the motivation that got me started as well, so I can confirm that :) > One last thing: is there a CVS tree in place for the Mailman source? Yup, see <URL:http://www.python.org/mailman/listinfo/mailman-checkins> for info on how to access it. -- Harald

1 0

RE: [Mailman-Developers] An NT Mailman version
by Tom Funk 09 Aug '99

09 Aug '99

Dan: Thanks for getting back to me. Do you, or anyone else on this list, know of any attempts to recompile the core C source files using the Cygnus' cygwin product? One of the design goals of cygwin was to mimic fork(), spawn family of functions that are missing from the Win32 API. Dan said: >> will be in troubles with locking and forking... >> ...But if You wont use included archiving Is the locking and forking code only the archiving parts of the code? Or is it spread throughout the source? Has anyone considered porting the forking code to Python threads? I've not worked with them, but the impression I get is that for the O/S's that support them, they tend to be pretty non-os-specific. 'Course I may be wrong on this.... I'd consider working on an NT port. It's a *great* way to learn all kinds of things about a software package - and the implementation language. I'd just like to not start from scratch if at all possible. One last thing: is there a CVS tree in place for the Mailman source? I downloaded the source for Mailman, but don't recall seeing anything about revision/source code control. I seem to recall some discussion at the Starship Python site (http://starship.python.net) about hosting CVS trees for Python-based source code. If there isn't a CVS tree (or SCCS or RCS) then this might be an option. Just my $.02. -=< tom >=- -----Original Message----- From: Dan Ohnesorg [mailto:dan@feld.cvut.cz] Sent: Sunday, August 08, 1999 4:57 PM To: Tom Funk Subject: Re: [Mailman-Developers] An NT Mailman version On Thu, 5 Aug 1999, Tom Funk wrote: > > Is there a Windows NT version of Mailman in our future? I checked the > archives and didn't see anything about this (hope I didn't miss it.... :-). > > > Since Mailman is written in Python, and there are only six C programs, all > of which look *fairly* non-*nix specific, a port doesn't seem too > far-fetched. > > Any thoughts? I think You will be in troubles with locking and forking code in mailman under NT. But if You wont use included archiving, it will probably run good. cheers dan

1 0

Re: [Mailman-Developers] Configurable Archiving Proposal
by Harald Meland 06 Aug '99

06 Aug '99

[Paul Hebble] > This solution does not do what we want. It would either put > unapproved posts in the archive, Indeed -- sorry, I missed that. > We're looking for a clean solution. I posted a patch yesterday. Yup, didn't see your patch until after my hack idea was sent. I'll take a closer look at it when I get some spare time... -- Harald

1 0

An NT Mailman version
by Tom Funk 05 Aug '99

05 Aug '99

Is there a Windows NT version of Mailman in our future? I checked the archives and didn't see anything about this (hope I didn't miss it.... :-). Since Mailman is written in Python, and there are only six C programs, all of which look *fairly* non-*nix specific, a port doesn't seem too far-fetched. Any thoughts? -=< tom >=-

1 0

Re: [Mailman-Developers] RE: Mailman-Developers digest, Vol 1 #328 - 6 msgs
by Harald Meland 05 Aug '99

05 Aug '99

[Barry A. Warsaw] > >>>>> "HM" == Harald Meland <Harald.Meland(a)usit.uio.no> writes: > > HM> Like, in a separate frame, maybe? That's what I've been > HM> thinking, anyway... > > HM> However, the frame-full UI should be optional. For a > HM> frame-less UI, I agree with Ken. > > Harald, I hope you're not advocating using HTML <frame>s! I > absolutely detest those things :). I think we can get all the > benefits of frames without the headaches by using an arrangement > similar to www.python.org and www.jpython.org (and not-coincidentally > www.python.org/~bwarsaw :) I suspect that I'm not understanding the issues involved clearly enough to be advocation one or the other construct. However, mere suspicion of lack of understanding have never stopped me from putting my foot in my mouth before :) Here are some of possible uses I have been thinking about for HTML <frame>s in Mailman: * Implementing a admin-interface sidebar with links to the various admin pages * Viewing list option documentation in the same browser window as the admin interface * Keeping buttons like "submit changes" fixed in one window position while scrolling through all the settings in another frame (although this might very well be undoable due to the SUBMIT input being in another document than where the POST form is...) The sidebar stuff could be done with an arrangement like Barry suggests, even though then the entire page would have to be re-rendered when a new page is loaded, and the sidebar would scroll along with the rest of the page. Adding an option documentation row to the full-page table would only work properly if the entire page fits inside one windowful -- and would probably be messy even then. On the other hand, maybe the current approach of always showing option documentation in a separate window is the way to go. Having fixed-position buttons is not really that important, I think :) -- Harald

2 1

Re: [Mailman-Developers] Configurable Archiving Proposal
by Harald Meland 05 Aug '99

05 Aug '99

[Paul Hebble] > I want to set up Mailman to support other archiving methods, more cleanly > than subscribing a procmailrc to a list. I know a few other people are > interested in this as well. > > I would like to add a per-list configuration option to each list's > config.db which tells Mailman a command line to run to archive a > message. If you're looking for a quick hack to fix this (as opposed to a clean solution), I think this is yet another thing the per-list "filter script" could be (ab)used to do. Just have the filter make two copies to stdin, and send one to stdout (for the rest of Mailman to enjoy it) and one to your archiver pipe. -- Harald

2 1

Re: [Mailman-Developers] message board functionality?
by Harald Meland 04 Aug '99

04 Aug '99

[Barry A. Warsaw] > 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) Just a quick note: I think that when we add "user accounts" (which I think is what previously has been referred to as "user objects"), there shouldn't necessarily be any single "login name" associated with this account. Any of the email addresses that Mailman (in som way) verifies as belonging to the same user object should be able to work as login names. Remembering what Mailman login name you have on various servers could become just as much a PITA as remembering all those different passwords is. > and a password, and ask if they matched? First of all: I admit to not understanding the issues around the various authentication schemes implemented (more or less natively) in various web servers as well as I could. Be gentle. >From Paul Hebble's Kerberos patch, I thought that given a kerberized web server, the web server itself will do all the (site-specific) authentication without really needing to consult Mailman at all. The problem, then, is to create a clean interface between Mailman and kerberized/other webserver-based authentication methods. Whether any of this is at all relevant to John's situation is _way_ to complex for me to say anything about (yet) :) Are there any web gurus out there who have the pointers (or explanations) that could make all of this a bit clearer to me? -- Harald

1 0