At 6:13 PM -0500 9/5/96, Jason L Tibbitts III wrote:
>>>>>> "DW" == Dave Wolfe <email@example.com> writes:
>DW> I'd hoped that John and/or Brent would pipe up with what one of them
>DW> had posted here awhile back about plans for 2.0.
>I hope for the same. I don't think John is still here, and I know Brent is
>busy beyond imagination.
I think that the old Majordomo 2.0 working spec has been overtaken by
events (i.e., growth of the Web) and is largely irrelevant to what we
should do today.
>Anyway, here are my goals for future development. Yes, this is incredibly
>vague but some of these aren't my ideas so I haven't really developed them.
>Finally note that while I know something of the plug-in module idea I don't
>know many of the particulars and I really have no idea at the moment of how
>it might be done.
The idea is basicly that sites should be to add their own commands to the
Majordomo framework, as well as perhaps pre-process and post-process
existing Majordomo commands, without having to modify the base Majordomo
code. For example, Majordomo might look for module files in a particular
directory, which would contain code that would then be incorporated into
>Planned for 1.95:
>Add in various small features that have been requested during 1.94
> development but didn't make it in.
>Tighten up bad address checking and enhance instructional and warning
> messages given to list users.
Both good goals.
>Continue code cleanup. This phase basically boils down to cleaning out
> dead code, reorienting things to make them more readable, moving variable
> declarations to the top of the function, cleaning up variable names, etc.
There are times when the best thing to do with a function is throw it out
and write it from scratch...
>Goals for 2.x (in no order):
>Address list kept in database (x > 0).
Gotta be optional. Isn't necessarily appropriate for a list of ~100 or
less users; there are a LOT of Majordomo lists out that that are only 10 or
>Client/server model (x > 1).
>Plug in modules (x > 2).
>Break functions up into classes (this list is not inclusive):
> Address manipulation:
> Comment/Name stripping.
> Domain munging.
> Address list manipulation:
> Database accessors.
> Flat file accessors.
> Add/Delete an address.
> Check to see whether or not an address exists.
> Find matching addresses.
> Returning the address list.
> Configuration management.
> List information management:
> Return list info.
> Return new user message.
> Inform owner of various operations.
>(client/server communication happens here)
> External (email):
> Process a piece of email looking for requests.
> Send info returned by the internal functions back to requestors.
> External (cgi):
> you get the picture.
As I've posted elsewhere, I'd be tempted to do WWW first if I was starting
from scratch, and maybe not even bother to do an email interface to list
management functions (i.e., only handle routine user stuff via email).
> External (command line).
> External (telnet).
> External (what else is there? touch tone?)
If there's a WWW interface, I don't think these others are necessary.
>No globals. Pass refs to data structures around instead. Keep in mind
>that some structures may my accessed simultaneously be various forked
>copies of a server.
Tricky; probably needs to be coded from scratch to support this.
>Build resend functionality into the server. Mails are accepted by a tiny,
>possibly even C program that just contacts the server and sends the message
>over a socket to be delivered. Since we may not have addresses in a flat
>file, we'll have to talk SMTP ourselves. Incorporate some or all of TLB
This I have strong reservations about.
First, let's avoid C. I'd like to get rid of wrapper.c altogether; I'd
like to have never needed it in the first place, but it was necessary
because of bugs related to setuid code in the versions of perl that were in
common use when Majordomo was first written. Let's keep everything in one
Second, queue management is hard. That's why I left it to Sendmail, both
incoming and outgoing. We may not be able to avoid it forever, but I'd
like to avoid it for as long as possible.
Third, what do you mean by "talk SMTP ourselves"? If you mean "talk SMTP
to the local mailer in order to queue the outgoing message", that's fine.
If you mean "talk SMTP to each recipient mailer in order to deliver the
outgoing messages", that's a problem I definitely don't think we should
take on; leave it to Sendmail.
Fourth, what is TLB? :-)
Brent Chapman | Great Circle Associates | 1057 West Dana Street
Brent@GreatCircle.COM | http://www.greatcircle.com | Mountain View, CA 94041
Internet Tutorials from the Experts!