Re: PRZ encrypted voice software release imminent

[Ray Cromwell <rjc@clark.net>]

> 
> At 1:36 PM 8/11/95, Ray Cromwell wrote:
> 
> >  My question is, how portable is it, and does it work over TCP/IP rather
> >than just modem connections (I suggested this about a year ago)? My ideal
> >implementation would function on the following architectures:
> >
> >Unix: can be used through either /dev/tty?? or Socket (probably want
> >to use UDP). Works on Solaris, IRIX, AIX, NetBSD/FreeBSD/BSDI and Linux.
> >(audio devices are all proprietary)
> >
> >
> >Windows: uses Window's sound card device drivers, works via either
> >comport or WinSock
> >
> >Mac: uses Mac sound drivers, uses Mac modem port or MacTCP
> 
> From the "MacWeek" article, it initially runs on the Macintosh, using the
> sound capabilities built into (nearly) all Macs. Direct modem connections,
> with Internet versions to follow. (Windows to follow, too.)

  I just hope they isolated the operating system dependent code into
seperate modules so that "PlaySoundChunk(Chunk)" is used rather than 
"MacDeviceDriverCall(MacSpecificDeviceStruct, MacSpecificFormat)"
The application layer should be abstracted above the transmission
layer above the link-layer. At the application layer, communications
should be sent through the transmisson layer, e.g. 
"GetNextPGPFonePacket(Protocol, Packet)". The Protocol here would 
be TCPIPDriver or ModemDriver.  

  Therefore, all one would need to do to port it to different platforms
is code up a TCPIPDriver (for Unix == Berkeley Sockets, for 
Windows = Winsock, for Mac = MacTCP), code up a modem driver
(Unix = tty's + ioctl, Mac = Communications Manager, Windows = TAPI),
and finally port the SoundPlay and SoundRecord functions to the platform
dependent way of playing sounds and recording them.

  If you are forced to abstract above "modems", your algorithms will
be designed to work over more general transmission schemes. I fear
that coding for modems first will lead to an overall application tuned for
modems, but poorly designed for asynchronous networks. The tunning should
be done in the driver, not the application/algorithm level. 
(for example, modems don't experience much "packet churn and loss",
and they usually have a dependable bandwidth. Even if they retrain
randomly from 28.8 to 14.4, they can still be counted on to atleast have
9600 bps throughput more consistently deliverable than say a slip/ppp line 
would)


  Far too often on Macs and PC's I see code "welded" to specific hardware
dependencies. I only hope that PGPFone is more like PGP2.0 and less like
PGP1.0 (and less like HotJava, which is also a bitch to port), because
for general acceptable, I don't think it will succeed until it
atleast runs and interoperates on Mac, Windows, and Linux.


> The Mac may be a strange platform to develop on, to many of you, but it has
> some advantages. The sound tools are relatively standardized and are even
> built into the OS. Developers can thus count on what users will have.

   I don't think there is a problem with developing on the Mac. Atleast
the Mac has a real O/S. If it had been done for DOS first, it might have
been poking SoundBlaster registers with arcade magic constants in the
program. However, the application should be isolated away from its
I/O mechanisms so that all I/O is done through a module which
"maps" I/O requests to the local operating system mechanism, rather
than depending on them directly.

Sorry about the rant. (I haven't seen PGP phone's code, but I am
just remembering RealAudio/InternetPhone/VidPhone and a whole host
of other internet utilities that are either available only for windows,
only for Mac, or only for unix. Netscape seems to have done things
right.)

-Ray