Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!bionet!hayes.ims.alaska.edu!accuvax.nwu.edu!nucsrl!telecom-request
From: broehl@watserv1.waterloo.edu (Bernie Roehl)
Newsgroups: comp.dcom.telecom
Subject: Re: Prodigy Communications Protocol
Message-ID: <15241@accuvax.nwu.edu>
Date: 4 Dec 90 18:41:27 GMT
Sender: news@accuvax.nwu.edu
Organization: TELECOM Digest
Lines: 30
Approved: Telecom@eecs.nwu.edu
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 10, Issue 867, Message 8 of 14


In article <14775@accuvax.nwu.edu> rsm@math.arizona.edu (Robert S.
Maier) writes:

>There have been a good many articles in TELECOM Digest complaining
>about Prodigy.  Besides Prodigy's policies, many posters are irritated
>by their inability to capture Prodigy output to a file.

>Has anyone done anything about this?  I gather Prodigy uses a
>proprietary communications protocol, but is it possible to
>reverse-engineer it?  That would open the door to custom-designed
>Prodigy clients, running on any architecture.  And it would facilitate
>the addition of new features, such as capturing text and graphics
>output.

Hmm.  Isn't Prodigy using NAPLPS?  If so, it should be easy enough; in
fact, the software that Bell Canada is distributing for users of its
Alex system should do the job quite well.


Bernie Roehl, University of Waterloo Electrical Engineering Dept
Mail: broehl@watserv1.waterloo.edu OR broehl@watserv1.UWaterloo.ca
BangPath: {allegra,decvax,utzoo,clyde}!watmath!watserv1!broehl
Voice:  (519) 885-1211 x 2607 [work]


[Moderator's Note: Because the gateway to comp.dcom.telecom was off
line for a couple of days, we have a lot of late replies coming in.
But again I must ask that we conclude the Prodigy thread at this time.
There is little more to add to the discussion.   PAT]