rsm@math.arizona.edu (Robert S. Maier) (11/19/90)
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. Or is it simply too difficult a job? Robert S. Maier | Internet: rsm@math.arizona.edu Dept. of Math. | UUCP: uunet!arizona!amethyst!rsm Univ. of Arizona | Bitnet: maier@arizrvax Tucson, AZ 85721 | FAX: +1 602 621 8322 U.S.A. | Voice(POTS): +1 602 621 6893 / +1 602 621 2617
evan@telly.on.ca (Evan Leibovitch) (11/19/90)
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. I have never used Prodigy, nor do I know much about its present form (except for the glowing comments it gets here in TELECOM :-). But I seem to recall that Prodigy is an outgrowth of what was once called "Trintex", which included IBM, Sears and CBS. When CBS pulled out, the "Tri-" prefix was no longer appropriate. If Prodigy is indeed what was once Trintex, then the protocol being used is NAPLPS (North American Presentation Level Protocol Syntax), which evolved from the Canadian "Telidon" protocol. If so, there are a couple of companies out there selling PC-based NAPLPS display software which may be better than what Prodigy offers. A company called Formic, based in Montreal, comes to mind. NAPLPS is a very efficient way to transmit shape-based graphics images over serial lines, in a manner that's supposed to be device- and resolution independent. It has been accepted as a standard by ANSI, though it never cought on in the market as well as proponents had hoped for. If Prodigy is not based on NAPLPS... never mind :-) Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario evan@telly.on.ca / uunet!attcan!telly!evan / (416) 452-0504
nelson%odin.corp.sgi.com@sgi.com (Nelson Bolyard) (11/21/90)
In article <14775@accuvax.nwu.edu> rsm@math.arizona.edu (Robert S.
Maier) enquired about the protocol used by Prodigy. I'm not a Prodigy
subscriber, but used to work as an engineer in the videotext market.
I had an AT&T videotext terminal that was similar to Prodigy in
drawing speed, and the way it drew pictures.
Videotext in the USA was based on NAPLPS (pronounced nap-lips) the
North American Presentation Language Protocol Syntax. 'Twouldn't
surprise me a bit to see that AT&T revived that technology for
Prodigy. Prodigy strikes me as the ultimate resurrection of videotext
in the USA.
Maybe TELECOM Digest's readers include someone who still has a copy of
the NAPLPS standard and who could take a peek at a Prodigy data stream
to see if it looks familiar.
Nelson Bolyard nelson@sgi.COM {decwrl,sun}!sgi!whizzer!nelson
Disclaimer: Views expressed herein do not represent the views of my employer.amanda@visix.com (Amanda Walker) (11/30/90)
In article <14869@accuvax.nwu.edu>, nelson%odin.corp.sgi.com@sgi.com (Nelson Bolyard) writes: > 'Twouldn't surprise me a bit to see that AT&T revived that technology > [NAPLPS] for Prodigy. Back during my very brief tenure as a Prodigy user, I poked around some in the Macintosh client software (trying to figure out why it was so unfriendly to the rest of the Mac). I ran across several pieces of code that had debugging messages & debugger symbols which referred to NAPLPS. I never peered at the actual data stream, but all of the screen displays are certainly well within the capability of vanilla NAPLPS. The first time I signed on, in fact, my first thought was, "my god, this looks like Telidon back from the grave" :). Amanda Walker
russell@spdcc.com (Tim Russell) (12/02/90)
From article <14869@accuvax.nwu.edu>, by nelson%odin.corp.sgi.c om@sgi.com (Nelson Bolyard): > Maybe TELECOM Digest's readers include someone who still has a copy of > the NAPLPS standard and who could take a peek at a Prodigy data stream > to see if it looks familiar. Prodigy online documentation confirms that the Prodigy software does indeed use the NAPLPS videotext standard. \TR/ Tim Russell \/ Omaha NE russell@spdcc.com
dave@uunet.uu.net (12/04/90)
The user's manual asserts that NAPLPS, North American Presentation Level Protocol Standard, is the communications protocol. But, it seems the tech support people at PRODIGY don't know this. They assert, wrongly, that the downstream communications is compressed bit-maps. Dave uunet!snowgoose!dave dave%snowgoose@uunet.uu.net
broehl@watserv1.waterloo.edu (Bernie Roehl) (12/05/90)
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]
hrs1@cbnewsi.att.com (Herman R Silbiger) (12/07/90)
In article <15214@accuvax.nwu.edu>, snowgoose!dave@uunet.uu.net writes: > The user's manual asserts that NAPLPS, North American Presentation > Level Protocol Standard, is the communications protocol. > But, it seems the tech support people at PRODIGY don't know this. > They assert, wrongly, that the downstream communications is compressed > bit-maps. NAPLPS is the North American Presentation Layer Protocol Syntax. It is not a protocol, but a syntax for the image coding. NAPLPS is resolution independent, and controls a variety of methods to actually produce the image. There are two other standardized videotex coding syntaxes, the European CEPT, and the Japanese CAPTAIN. All are standardized in CCITT Rec. T.101. A method for Videotex systems to interwork has been standardized and uses ODA (Open Document Architecture) as an interchange method. ODA uses ASN.1 (Abstract Syntax Notation One) as a syntax. I have no idea what the actual communications protocol is that Prodigy uses to communicate with the PC. Herman Silbiger hsilbiger@attmail.com