"Jesse Guardiani" <[EMAIL PROTECTED]> writes: > They have their place. You can't put TMDA on a 500 domain mail > server and expect each user to learn UNIX and TMDA just to filter > their mail.
But those are your users, not mine. I don't have the resources or interest to handle hundreds of users who can't problem solve yelling ``I pressed Install and my email broke. Help!!!''. > Granted, admins need to learn how TMDA works under the hood That's really what I was referring to. The "first tier" of users so to speak. > TMDA will never see mass use This isn't necessarily a bad thing. > until a decent (read: NOT qadmin-tmda) 'magic gui' is created and > maintained. That's fine, but I'm not going to write it. It's not interesting work to me, and as I mentioned, such things tend to be huge time sinks. Perhaps this is why qadmin-tmda was so short lived. > Only if it's written poorly. It's just a program like any other. It's not quite like any another. The problem with a one size fits all magic-gui is that there are lots of different shapes and sizes out there, so it's very hard to write one tool that is going to work for everyone. As time goes on, you either have to turn users away or the magic-gui turns into an unmaintainable behemoth which consumes more time than all the rest of the project combined. The unsatisfied users then go and implement their own site-specific guis, and then you wonder why you made the effort in the first place. In short, imagine the phenomenon we've seen with tmda-pending times ten. Providing a framework to make it easier for large sites to implement their own custom guis is a better idea. This is some support for this in today's TMDA modules, but it could probably be improved. _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
