From: Mike Barker Subject: Re: Large Scale Messaging Date: Tue, 19 Mar 1996 11:51:52 EST The Problem: Can we distribute messages to large groups of users? Short Answer: Use discuss. Benefits: the discuss model is well-understood and supported. All that is needed is creation of the appropriate lists on an appropriate server plus publicity to let the users know they should be reading certain lists. A modified set of clients can make this even easier, but most of the benefits can be gotten without even doing that. The Possibilities: 1. Email distribution. Clearly this seems like the simplest for the people sending messages. Unfortunately, the development and maintenance of the lists of names and the processing loads of such bulk mailings both are unreasonable. 2. motd distribution. This lacks the ability to only target certain groups. 3. lert. this system was developed for deactivation messages. it does NOT support a large set of messages and the administration tools are primitive. further, using it for "bulk mail" type messages would reduce the urgency of message use that it is intended for. for more details, see http://web.mit.edu/mbarker/www/ideas/lert0306.txt 4. discuss. I believe the discuss service provides a model that can easily be enhanced to deal with bulk mailing needs here at MIT. Basically, all that is needed is a set of discuss meetings for each group or category to which people want to send messages (e.g., classof1996, classof1997, and so forth; course6, course2, etc.). Then when someone wants to send a message to all seniors, for example, they simply compose the email and send it to the correct discuss meeting. The seniors read it using the client of their choice. A specialized program could be provided for accounts to help them set up the users original .meetings file. A slightly easier to use variation would be to make "hacked" discuss clients which worked from a personalized .meetings (or .profile) file and automatically pulled in and displayed urgent messages. This is not especially necessary, although it might help sell the use of discuss meetings as a generalized bulk mail facility. Note that this keeps the processing load off the mailhubs. We know how to distribute the discuss servers if necessary. The development and maintenance of mailing lists is reduced, since the user maintains their own .meetings lists rather than requiring some central administration to do so. All that the administrators have to do is keep a set of discuss meeting names up to date (e.g. add a new classofxxxx each year). Finally, this provides the senders of messages with the same simple email interface that bulk mailing would provide. The only difference is that instead of their mail going to the mail services, it goes into the discuss servers. mike ------------------------------------------------- From: Gregory A Jackson Subject: Re: Large Scale Messaging Why not send that message to ACMG, to help our (er, um) discussion? Personally I have some trouble with your answer -- for example, although a Windows discuss cleint was promised two years ago it doesn't yet exist, Discuss provides no mechanisms for enclosures, and most of all it's a proprietary rather than a general solution -- but the deeper idea that send-to-many is an inferior protocol to many-look-at-one is right on. gj MIT e40-359a 617 253 3712 (voice) 1 Amherst St 617 258 8736 (fax) Cambridge MA 02139 http://web.mit.edu/gjackson/www/ ------------------------------------------------- Date: Tue, 19 Mar 96 13:39:18 From: jdb@MIT.EDU (James D. Bruce) Subject: Re: Large Scale Messaging Mike ---- The problem that I see with this approach is that discuss clients do not exist on all of the platforms for which email exists. One of the big demands I see is for faculty and administrative lists. A predominately Athena solution does not help too much in these cases. ......................................................jim ------------------------------------------------- Date: Tue, 19 Mar 1996 13:46:31 -0400 From: tjm@MIT.EDU (Tim McGovern) Subject: Re: Large Scale Messaging At 1:21 PM 3/19/96, Mike Barker wrote: >The Problem: >Can we distribute messages to large groups of users? >Short Answer: >Use discuss. This could be right. This note is being sent to the OCMG list as well as ACMG. I've reproduced Greg's original item, and Mike's reply in full below. It would seem appropriate to include the Office perspective here as well. It seems possible that there will a need for notices of an Administrative nature to be sent to hundreds or thousands of folks, so the need _sounds_ the same. What is the current and planned status of client software for Discuss? What is the current assessment of the hypermail/webmeet software? What other commercial options exist? Could one of these commerical options reduce or eliminate sw maintenance? Tim ----- Greg's Message: X-Sender: gjackson@po8.mit.edu Mime-Version: 1.0 Date: Tue, 19 Mar 1996 09:35:33 -0500 To: acmg@MIT.EDU From: Gregory A Jackson Subject: more 3/26 3-5 e40-212 In addition to the RFP item I already announced, we'll have another topic next Tuesday: Mailing lists (reprise) (Schiller) We're being asked in various quarters once again about large mailing lists, such as whole classes or houses or departments. One of the issues is list manageability; UNIX tools are rather poor, and hand-intensive, but LISTSERVs have their own problems. Another issue is consent: Under what circumstances to we put someone on a list without that person's consent? Problem is, if we continue to do nothing about this, then someone else will simply bypass us to provide the service our customers want. So time rather presses. Anyway, should be a full meeting. Hope to see everyone there! gj MIT e40-359a 617 253 3712 (voice) 1 Amherst St 617 258 8736 (fax) Cambridge MA 02139 http://web.mit.edu/gjackson/www/ ----- Mike's reply: To: acmg@MIT.EDU Subject: Re: Large Scale Messaging Date: Tue, 19 Mar 1996 13:21:54 EST From: Mike Barker The Problem: Can we distribute messages to large groups of users? Short Answer: Use discuss. Benefits: the discuss model is well-understood and supported. All that is needed is creation of the appropriate lists on an appropriate server plus publicity to let the users know they should be reading certain lists. A modified set of clients can make this even easier, but most of the benefits can be gotten without even doing that. The Possibilities: 1. Email distribution. Clearly this seems like the simplest for the people sending messages. Unfortunately, the development and maintenance of the lists of names and the processing loads of such bulk mailings both are unreasonable. 2. motd distribution. This lacks the ability to only target certain groups. 3. lert. this system was developed for deactivation messages. it does NOT support a large set of messages and the administration tools are primitive. further, using it for "bulk mail" type messages would reduce the urgency of message use that it is intended for. for more details, see http://web.mit.edu/mbarker/www/ideas/lert0306.txt 4. discuss. I believe the discuss service provides a model that can easily be enhanced to deal with bulk mailing needs here at MIT. Basically, all that is needed is a set of discuss meetings for each group or category to which people want to send messages (e.g., classof1996, classof1997, and so forth; course6, course2, etc.). Then when someone wants to send a message to all seniors, for example, they simply compose the email and send it to the correct discuss meeting. The seniors read it using the client of their choice. A specialized program could be provided for accounts to help them set up the users original .meetings file. A slightly easier to use variation would be to make "hacked" discuss clients which worked from a personalized .meetings (or .profile) file and automatically pulled in and displayed urgent messages. This is not especially necessary, although it might help sell the use of discuss meetings as a generalized bulk mail facility. Note that this keeps the processing load off the mailhubs. We know how to distribute the discuss servers if necessary. The development and maintenance of mailing lists is reduced, since the user maintains their own .meetings lists rather than requiring some central administration to do so. All that the administrators have to do is keep a set of discuss meeting names up to date (e.g. add a new classofxxxx each year). Finally, this provides the senders of messages with the same simple email interface that bulk mailing would provide. The only difference is that instead of their mail going to the mail services, it goes into the discuss servers. mike ------------------------------------------------- Subject: Re: Large Scale Messaging Date: Tue, 19 Mar 1996 14:49:45 EST From: "Reid M. Pinchback" I just read the message the Tim forwarded around about this. There are some things I'd like to feed in about current operational limitations that we may want to find ways to address: 1. Sometimes the "users add themselves to the list" model is not effective. For example, faculty members are sometimes unwilling to use lists for distributing class information unless they are certain that *all* students are on the list. Since there is no easy way to enforce a request on the students to subscribe, particularly in a large class, there really needs to be a way to easily populate large lists from other sources of information (like the registrar). Currently such efforts are mostly manual. 2. Some lists that are important to internal MIT activities can have significant memberships that include people outside of MIT. Right now the only way to maintain such lists is to have somebody here at MIT manually add and drop the external members. As such lists become more active, the manual maintenance becomes a problem. An example would be "users group" lists or cross-institutional efforts like the ECSEL coalition. 3. One of the nice things about Discuss is that the bits live somewhere permanently. It would be nice to not lose this feature, but if we use Discuss more then we might eventually get to a point where we need to re-evaluate how this persistence works so that the servers don't run out of diskspace or users end up with hard-to-search volumes of old messages. 4. Whatever solution we come up with, we'll probably need to think about how it fits in with Web-based activities. For example, the archive-like nature of Discuss makes it as desirable to read and search through meetings via a web browser as would be the case for any other network-accessible source of information like Gopher or WAIS. =============================================================== = Reid M. Pinchback = = Senior Faculty Liaison = = Academic Computing Services, MIT = = = = Email: reidmp@mit.edu = = URL: http://web.mit.edu/reidmp/www/home.html = =============================================================== ------------------------------------------------- Subject: Re: Large Scale Messaging Date: Tue, 19 Mar 1996 15:18:08 EST From: Carla Fermann Hi, Actually, this problem was solved years ago; it was just never implemented. What we need is angora, with Unix, Mac, and Windows clients ;-) (see the angora meeting on menelaus). In User Accounts, we try to get people to use discuss for situations like this, and run into resistance. Among the complaints are: - people aren't familiar with discuss, and don't want to learn another application - people don't want to rely on their intended audience learning and using another application - maintaining discuss acls for large numbers of people is a pain, especially because you can only include individuals and not lists - because the individual user controls which meetings he reads, there's no way for the owner of the meeting to automatically set it up so that people will read it. The owner can add a person to the acl, but if the individual doesn't add the meeting they won't see it. - there's no way for the owner of the meeting to tell who has added it and who hasn't, whereas with a mailing list you can see who is on it Discuss is the best solution we have currently, but it is far from ideal for this type of problem. Carla ------------------------------------------------- Subject: WebMeet Date: Tue, 19 Mar 1996 16:26:21 EST From: David Lukas Tim -- Naomi asked me to send you a note on the status of WebMeet, with regard to your need for a mechanism to distribute messages to large numbers of users. A more general discussion on WebMeet (targetted for academic use) is in the current Athena Insider; you can access the article on the Web at http://web.mit.edu/acs/www/insider/winter96.html#webmeet WebMeet is a Web bulletin board. Submissions can be made from HTML forms or via email. The main advantage of WebMeet is that it uses a Web-browser interface and can be run from any platform with a forms-capable browser. There a number of disadvantages that might make WebMeet unsuitable for your purposes. One is that, as with discuss, a user needs to specifically check a Web page, and does not get notified on login of the new message. Another is that large numbers of nested or overlapping groups would be cumbersome to maintain. Also, there is very little privacy (MIT-mostly is the best you can hope for) unless you require users to be on Athena and access the files through AFS. Also there is currently no way to limit who can submit messages. David Lukas (dlukas@mit.edu, 617-253-1459) Faculty Liaison Office (f_l@mit.edu, 617-253-0115) Academic Computing Services / MIT Information Systems -------------------------------------------------