Interlisp / medley

The main repo for the Medley Interlisp project. Wiki, Issues are here. Other repositories include maiko (the VM implementation) and Interlisp.github.io (web site sources)
https://Interlisp.org
MIT License
369 stars 19 forks source link

Revive CHATSERVER for 'terminal' access to Interlisp via telnet, XNS and stdin/stdout #1143

Open masinter opened 1 year ago

masinter commented 1 year ago

I've been wanting some way to invoke Medley as a kind of server, telling it to TEDIT HARDCOPY a TEDIT FILE to pdf, or prettyfileindex a file to get a reasonable listing, on demand. The CHATSERVER function had different plug-ins for different protocols. Running it on a server you can SSH to would be dandy. dIn any case, CHATSERVER doesn't work for reading /dev/stdin and /dev/stdout even when I cl:open {UNIX}stdin :DIRECTION :INPUT and stdout with :DIRECTION :OUT :IF-EXISTS :ADPPEND. This is less like a disk file than it is a PROCESS-STREAM.

Not completely sure of what is wanted, but at a minimum update the "simple" chat server to use \OUTCHAR.EOLC instead of BOUT (or maybe it was INCHAR.EOLC and BIN?). Test with CHATSERVER-NS and new DoDOimplementation.

You don't want it to show up in the list of (OPENP)'s. There are some devices {Linebuffer} and {Keyboard} that I don't understand. Can we use CREATE-PROCESS-STREAM("cat") ?

Finally, the "bug" part: when I try to do a look of \INCHAR to \OUTCAR of IN and OUT I get a memory smash sometimes and sometimes a "Device error". There might have been an attempt to FORCEOUTPUT (which seems like a synonym for FLUSHOUTPUT).

masinter commented 1 year ago

There are several "asks" in this: A way to RPC or otherwise get into a "server" medley that responds to requests from the command line or a remote client. This was called "CHATSERVER" rand there are a number of CHATSERVER-* files for each protocol. Fix these and test them as possible.

Second, related but different... some other way to communicate to a "remote" device using HTTP REST or other 'modern' API interface means.

nbriggs commented 1 year ago

There are implementations of both ONC RPC (i.e., SunRPC) and XNS Courier for doing RPC. The TCP/IP code underpinnings need work. There are SUBR implementations for various socket related operations so that the Lisp code can use the underlying OS implementation of TCP/IP, but it needs a higher level interface that should probably reflect something like the higher levels of the original Lisp-only TCP implementation so that code that was written assuming that interface would require minimal updating to work again.

If HTTP APIs are wanted, then for the client side we need to decide whether that should be a pure Lisp implementation on top of the TCP stack or whether we should introduce a dependency on, say, libcurl (available on at least macOS, FreeBSD, various Linux).