Subject: Re: lpd and appletalk
From: [email-masked] (David Empson)
Date: Wed, 15 Jun 1994 12:31:05 GMT
Newsgroups: comp.sys.apple2.gno

In article <[email-masked]>,
Phillip Vandry <[email-masked]> wrote:
> [email-masked] (David Empson) writes:
> 
> >> >>  I'd have to write a .atalkprinter driver for GNO.
> >> 
> >> How about instead a generic Appletalk raw communication device, which can
> >> open any device by name, and send/receive. The printer specific protocols
> >> could be implemented in a front end.
> 
> >This won't work, unless you limit it to "printer" devices.  You have
> >to use the appropriate AppleTalk protocol to talk to different
> >devices: PAP (Printer Access Protocol) is used for all printers, but
> >other devices (such as modems) may have a completely different
> >protocol.
> 
> Yeah, but it still runs over Appletalk protocols. 

Which protocol are you suggesting that the driver should implement?

Datagram Delivery Protocol is the lowest level that it is reasonable
to go, and at this level, you are sending individual packets to a
numbered socket on specified node.

AppleTalk Transaction Protocol is the next possibility, but you still
aren't opening a "connection" - you are sending individual
transactions (request/reply), again to a numbered socket on a specified
node.  There is no standarization for the contents of the requests and
replies - it depends on what you are talking to.  You would need more
control over this than a simple I/O stream.

(You can use Name Binding Protocol to map a specified name to the
correct socket and node address, but you need to know the three parts
of the name: object, type and zone.)

AppleTalk Session Protocol and Printer Access Protocol are based on
ATP, and are the only protocols that implement a connection scheme.
ASP is used by AFP (file severs).  ASP and PAP have little in common.

(There is also AppleTalk Data Stream Protocol, which isn't implemented
in the IIgs.)

> I don't see why the PAP protocol couldn't be implemented as a front
> end.

Because you'd be reimplementing the code which Apple have already
supplied, which is a rather wasted effort, for little or no gain.

It might cause confusion if something tried to use the real PAP while
your reimplemented PAP was active.  (Probably not, from looking at how
the protocol works.)

> I have some UNIX utils that allow an Appletalk device to be opened by
> name.

It probably uses PAP.  Do you have source for them?

> >PAP supports bidirectional communications, but ImageWriters don't use
> >the return data path (I don't know about LaserWriters).
> 
> Why not? "ESC ?" returns data, at least in serial mode.

It doesn't do anything with a networked ImageWriter.  The ImageWriter
can supply status information, which has a bit field indicating which
printer options are installed (colour ribbon, sheetfeeder), and what
state the printer is in (busy, out of paper, cover open, offline,
paper jammed, fault, active).  This is interpreted by the Print Manager
ImageWriter driver and displayed in an alert box if there is a problem.

Reading/writing data and returning status are separate operations in
PAP.  The PAPOpen and PAPStatus calls return status information.  The
ImageWriter will never return any data via the PAPRead call.

I'm pretty sure that the LaserWriter _does_ use the return data path,
as well as the status mechanism (it sends text messages indicating
what the printer is doing).

See TN.ATLK.009 for further details about the status messages returned
by the ImageWriter and LaserWriter.
-- 
David Empson
[email-masked]
Snail mail: P.O. Box 27-103, Wellington, New Zealand