Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!iuvax!bsu-cs!mithomas
From: mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus)
Newsgroups: comp.sys.mac
Subject: Re: What I'd like to see in the AppleShare of the 90's
Keywords: accounting, communications
Message-ID: <10584@bsu-cs.bsu.edu>
Date: 17 Jan 90 06:54:52 GMT
References: <25184@brunix.UUCP> <25862@cup.portal.com> <25447@brunix.UUCP> <25942@cup.portal.com> <1990Jan15.173834.27744@phri.nyu.edu> <581@gargoyle.uchicago.edu> <19068@netnews.upenn.edu> <583@gargoyle.uchicago.edu>
Reply-To: mithomas@bsu-cs.UUCP (Michael Thomas Niehaus)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 21

I don't see that it is necessary to add Broadcast-type features to
AppleShare, since the ability to do such work is not dependent on the
existence of AppleShare.  Using normal AppleTalk calls, you can develop
a decent system.  What advantages would AppleShare add to this
setup?  (Or to use a cliche, what does AppleShare bring to the party?)

Someone should write an APPLICATION somewhat like Backgrounder that just
sits and waits for incoming messages.  When a message does come, the
Notification Manager should be used to notify the user that a message
is waiting.  They should then have to switch to that application to
read the message (or to send a message).  This prevents "rude interruptions"
of the current foreground application.

Any other opinions?

-Michael

-- 
Michael Niehaus        UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!mithomas
Apple Student Rep      ARPA:  mithomas@bsu-cs.bsu.edu
Ball State University  AppleLink: ST0374 (from UUCP: st0374@applelink.apple.com)