[Info-vax] Real-time new mail notification

[Bob Koehler]

In article <hbtkts$aep$1 at charm.magnus.acs.ohio-state.edu>, DAVISM at ecr6.ohio-state.edu (Michael T. Davis) writes:
> 
> 	At least in the case of Deliver, since it operates in batch mode,
> depending on the load of the given queue(s), the notification could be
> enqueued behind who-knows-how-many other jobs.  The built-in broadcast
> mechanism of VMS Mail occurs during message delivery, not sometime thereafter.
> In that sense, I would want the notification to operate in "real time" just as
> a VMS Mail notification does.

   VMS Mail has been described as an electronic messaging system, more
   than an electronic mail system.  In itself, there is no store and
   forward nor delayed transmission.  In it's original incarnation as
   operating only locally and over DECnet, either you could send the
   message immediatley, or not at all (I think this matches what you
   mean by real-time in terms of performance, although in delivery
   instead of notification).

   Since support for SMPT, which is a mail protocol with store and
   forward, as well as delayed transmission, VMS Mail interfaces to a
   real electronic mail system, but doing store and forward and delayed
   forwarding means not having that kind of real-time performance.

> 
> 	The end-users will not have a terminal session open to the VMS system.
> Instead, they run a MUA (e.g. Eudora, Thunderbird, etc.) and whatever program
> provides the functionality I'm hoping to find (though it sounds increasingly
> less likely I'm going to).

   But if the message is still backed up in a DELIVER queue, what good
   does it do to tell the user that DELIVER has received it?