2 Aug
2022
2 Aug
'22
11:02 p.m.
On 2022-08-02 22:43, Paul Koning wrote:
I can sortof understand what they tried to do. It's just that it's not a
good idea anyway. That offloading to the remote system makes it way too
complex.
I know it's not too hard. Just needs to be done. In the RSX
distribution, they are four different programs which share some code
between them, but each just do one protocol. But they do detect if the
remote speaks another variant, and refuses to continue in that case.
Maybe something for me to poke at one day. Unifying four programs into
one... :-)
I hadn't heard of that. You might send me some more info, off line if preferred.
Probably better doing that offline. But if you log into MIM, you can try
running it and see. Just NTD to look at the local node, or NTD <host> if
you want to look at a remote node.
? to get some interactive help.
Oh. :-) Makes more sense. :-D
Actually, I realized that the DTR server side is called DDM, at least in
RSX. Object 30. If you have a client, you can query the DECnet nodename
database on MIM using it. ;-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Aug 2, 2022, at 4:36 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2022-08-02 17:43, Paul Koning wrote:
Probably not. Cterm is not actually any better than what it replaced; the underlying
notion was to create a framework for other modes (like forms and editing). If that had
actually happened the protocol would have some redeeming features, but it didn't.
Cterm in Python should be fine. It's been on
my "to do at some point" list for a while now. The main difficulty is that
Cterm is a large and complicated protocol. The earlier "RMterm" suite of
protocols (it's really four, wrapped in a single object number) would be a good first
step. For one thing, most systems support it, and a few like RSTS support nothing else.
CTERM is way complex, yes. Not something I'd recommend people to work on general, but
I know that you can probably sort it out, Paul. But do you want to? The main good thing Cterm ever did was prompt the
creation of LAT (because Cterm, running on an F-11 based comm server, was such a horribly
sucking performer that it was obviously not fit to ship, and something else was urgently
needed).
:-)
The various
remote terminal protocols using object 23 is probably much easier, but there you do have
to do some clever things to figure out what the remote system is, and then it's
different protocols...
Actually, that part is easy. It starts with a "config" message exchange, and
that says which protocol to run. So the client connects, looks at the config response,
and branches off to one of four engines. It's simple enough even RSTS can do it. :-)
As for future plans, I don't have any specific
ones listed right now. I can think of a couple. More applications -- make sure DAP is
complete enough, perhaps mail, remote terminal, even more obscure ones like DTR and
Netcpy.
May I make a wish for NTDEMO? It's a protocol only RSX speaks right now, but it's
a really nice tool to get some insight into performance of remote systems. I can help work
out the protocol if needed. DTR? Client
then, I assume? Or do you plan to hook up to some database engine and play server side as
well?
Oops, ambiguous TLA. I meant DTR the test data receiver -- half of the
"dtsend" and "dtreceive" pair.