kent@circus.camex.com (Kent Borg) (07/24/90)
I have a question that I think should be handled by something in the
Communications Toolbox, but suspect it isn't:
When the phone rings, who answers?
With 7.0 there is a big push for communications. Interapplication
communications is great for applications on a given machine or the local
network, but what about communications with remote Macintoshes?
Say I want to write a program which phones up other copies of itself and
trades information, do I have to open the serial driver and just stay parked
forever waiting for a call?
At the risk of upsetting my stomach, I point out that Unix handles this
problem by having a login process which brings up your favorite shell which
can then run uucp, etc.
Is there some way for applications to get the Comm Toolbox to somehow
route incoming calls? I don't want to be a serial port hog.
--
Kent Borg internet: kent@camex.com MacNet: kentborg
H:(617) 776-6899 W:(617) 426-3577
"If 2 + 3 is always going to be 5, why do they keep teaching it to us?"
- 5-30-90 New York Times quoting a first graderausting@Apple.COM (Glenn L. Austin) (07/26/90)
kent@circus.camex.com (Kent Borg) writes: >I have a question that I think should be handled by something in the >Communications Toolbox, but suspect it isn't: > When the phone rings, who answers? >With 7.0 there is a big push for communications. Interapplication >communications is great for applications on a given machine or the local >network, but what about communications with remote Macintoshes? >Say I want to write a program which phones up other copies of itself and >trades information, do I have to open the serial driver and just stay parked >forever waiting for a call? >At the risk of upsetting my stomach, I point out that Unix handles this >problem by having a login process which brings up your favorite shell which >can then run uucp, etc. >Is there some way for applications to get the Comm Toolbox to somehow >route incoming calls? I don't want to be a serial port hog. If I understand you correctly, you want something from the modem that tells your application to answer with the modem. As far as I know, the only way to do this is to set up your modem for auto-answer, then go away and poll the carrier detect line for the connection. Not exactly the thing to do (IMHO) on the Mac and with the serial ports, since you're still tying up the port with the modem and the polling. However, if you just want it to sit there and wait for a call, then the CTB and the Modem Tool should work fine. -- ----------------------------------------------------------------------------- | Glenn L. Austin | "Turn too soon, run out of room, | | Auto Racing Enthusiast and | Turn too late, much better fate" | | Communications Toolbox Hacker | - Jim Russell Racing School Instructors | | Apple Computer, Inc. | "Drive slower, race faster" - D. Waltrip | | Internet: austing@apple.com |-------------------------------------------| | AppleLink: AUSTIN.GLENN | All opinions stated above are mine -- | | Bellnet: (408) 974-0876 | who else would want them? | -----------------------------------------------------------------------------
peirce@claris.com (Michael Peirce) (07/27/90)
In article <1435@camex.COM> kent@camex.com (Kent Borg) writes: > >I have a question that I think should be handled by something in the >Communications Toolbox, but suspect it isn't: > > When the phone rings, who answers? I've been thinking about this too. I think there is a solution using ApplEvents. The basic idea would be to a "switchboard" application running that allocates the modem port(s) and does the listening for ring thing. If it detects someone calling, it initiates a login-like sequence that trys to figure out what other program is appropriate to connect to (BBS, UUCP, Timbukto-Remote, etc) or a default. This App would then send an event to the appropriate App and tell it to take over the link. After the session is over, control should be returned to the switchboard app via another event. Another part to this scheme is to have a yield port message that can be sent to the switchboard App. This would allow me to fire up AppleLink and get the port away from the switchboard app. Has anyone been active in defining Communications ApplEvents? This kind of think seems even more important with the coming of ISDN. Without a good convention for establishing who the incoming call is for the utility of it diminishes greatly. Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 5201 Patrick Henry Drive MS-C4 | Box 58168 | Santa Clara, CA 95051-8168 | (408) 987-7319 | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}!claris!peirce it to take over the link.