2 Aug
2022
2 Aug
'22
10:43 p.m.
On Aug 2, 2022, at 4:36 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2022-08-02 17:43, Paul Koning wrote:
You should. :-)
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?
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.
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).
On Aug 2,
2022, at 11:25 AM, Brian Angus <brian.angus(a)gmail.com> wrote:
I like that idea, although I do wonder how many "real" applications would
really need, want, or even try to support DECnet directly in these modern times? For the
terminal server case that I am initially interested in building, CTERM and a few network
diagnostic tools would keep me very satisfied, Adding in some file transfer capabilities
would be simply awesome.
The latest (T1.1) has basic DAP support. I should do a
V1.1 release; it's been long enough to leave beta stage. It would
be really useful even if some of these functions were only exposed through internal
PyDECnet sub-commands instead of being available system-wide. I've been happily using
PyDECnet for a couple of years, but I haven't yet upgraded to your new test releases,
and I haven't kept up on what all is included in your future plans? Regardless, I
suspect that any somewhat easier way to keep a version of DECnet running on Linux with
even the minimal set of tools would be appreciated by many around here. How do you think
the performance would be with CTERM written in Python?
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. 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.
But yes, DAP, both server and client, are pretty
useful...
I have them in T1.1, at least as a start. Not quite solid yet but some of the basic
operations work.
paul