Newsgroups: comp.sys.apple2.gno Path: blue.weeg.uiowa.edu!news.uiowa.edu!uunet!usc!elroy.jpl.nasa.gov!decwrl!waikato!comp.vuw.ac.nz!actrix.gen.nz!dempson From: dempson@actrix.gen.nz (David Empson) Subject: Re: lpd and appletalk Message-ID: Organization: Actrix Information Exchange References: <2t6dvh$svp@ns.oar.net> <2tg30h$ejl@altitude.hip.cam.org> <2tj590$s4u@altitude.hip.cam.org> Date: Wed, 15 Jun 1994 12:31:05 GMT Lines: 83 In article <2tj590$s4u@altitude.hip.cam.org>, Phillip Vandry wrote: > dempson@actrix.gen.nz (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 dempson@actrix.gen.nz Snail mail: P.O. Box 27-103, Wellington, New Zealand