Roger; PLEASE understand this is not directed toward you, although I am using your letter as a starting point for my own, since your views seem to be in many cases the majority view of those on the list. Everyone Else; At 12:25 PM -0400 7/28/00, Roger Burton West is rumored to have typed:
OK. What does a web interface for smartlist need?
Nothing, IMHO. It is possible that some inept admins might need a web-based system, I suppose, but SmartList doesn't really need one.
The most basic version would simply send appropriately-formatted X-Command: mail to the list-server. That's fairly trivial to get right.
You're right, having written a couple of 'em myself for different (and inept) clients. But it's even _more_ trivial to simply send an X-Command: via email and be done with it. No, really, it's simple. Mind numbingly easy. Why does everyone make it so tough? (I know I keep saying this. But I am _truly_ perplexed - it's as if someone told me that it was difficult-if-not-impossible to tell time on a digital watch...I just can't understand the confusion.)
But I'm considering the possibilities inherent in a slightly larger CGI, which might be run suid to the list user, which could maniupulate the list data files directly - to check authentication, add/remove users, and so on.
Why would you bother to do something like that, when SmartList already handles it quite nicely? If you're going to waste the time doing that, you should probably just write a new mailing list software package and be done with it. (Gee, inbound email already runs as the list user, so no external suid required. SmartList already handles adding and removing users, even locking the dist file so it doesn't step on itself. Wow...it actually does all the things you're reinventing already. Simple, ain't it?)
As for the user side, how would you prevent malicious foreign unsubscriptions without a password? The existing "confirm" patch from aks would be helpful, here.
You mean _is_ helpful here. It already exists; why re-invent it?
Do we want a mhonarc-like archiving system, given that mhonarc is pretty easy to integrate with smartlist already?
Again, it's a MAILING LIST. If you want to work on the Web, use Phorum or another piece of BBS software. "We" don't want a web-based archiving system; for those who do, mhonarc already exists - why re-invent it. But this part of "we" is happy as punch with the email-based search engine. (If you don't like the existing email search mech, please feel free to re-write it; that's what open-source means.) And at the risk of alienating three quarters of the subscribers to this list, I have to say that if you can't figure out how to use an X-Command, given all the examples all over the place (see the Manual and the .examples directory), you shouldn't be running _any_ mailing list server. Use Topica or eGroups and save yourself a lot of grief. If you don't understand the simple concept of the X-Command, you shouldn't be adminning _anything._ And if your potential subscriber is too stupid to subscribe without you needing a Web-based X-Command system to send a subscribe X-Command, do you really need _that_ subscriber? (My tolerance for people who can't follow the simple confirm instructions is long past exausted.) That sounds to me like the blind leading the blind... Look, folks, if maintaining SmartList were difficult, I'd understand all the hand-wringing about Web-based tools. But good grief, it pretty much maintains _itself,_ and the maintainer only has to get involved occasionally when the potential subscriber is unable to follow simple subscription instructions, or the procbounce routines can't figure out the address because a Lotus Notes mail server doesn't know how to send a properly-formatted bounce. So where exactly is the tremendous _need_ for Web-based maintenance packages? I honestly don't understand it. Can _anyone_ explain why using a web server to control a mailing list as simple to maintain as SmartList is a "good thing?" Charlie