🚀 go-pugleaf

In article <19960523.072920.61@compton.demon.co.uk>
    tom@compton.demon.co.uk (Tom Hughes) writes:

> In article <832786725snz@dsl.co.uk> Brian {Hamilton Kelly} (bhk@dsl.co.uk) wrote:
> 
> > I'm glad that was brought up eventually; since posting my original
> > message, I spoke to the colleague, who confirmed that it *was* the Acorn
> > version of KA9Q that also provided a TCP/IP stack for use by other
> > programs.  So I should have posted to d.i.s.archimedes, rathern than
> > d.i.s.amiga, in the first place.  Apologies to both sets of adherents.
> 
> Only sort of - nobody ever got quite as far as exposing a raw
> interface to the stack. What it does do is allow any application
> to execute a command as if it were typed at thw 'net>' prompt.
> 
> That, along with the 'trf' command, which sends a connects to a
> given port, sends a string and captures the data that comes back
> to a file allows things like the fetching of web pages or finger
> files by external programs.

To expand on what Tom said...

The Acorn is inherently multi-tasking with message passing between
applications.  So one part of the mod was simply to allow other applications
to send a message to KA9Q to be interpreted as a command.  From what I
understand of DOS KA9Q this would be a non-starter anyway.

The next part of the mod was to copy the finger client and modify it as
a trf (short for transfer, I assume) command which would send off a one-line
command to a designated site and port and dump whatever came back in a
scrap file.

The final part of the mod was that if the trf command was passed to KA9Q
from another app, then when the connection closed the name of the scrap
file was passed back to the original application.

Time passed, and the trf stuff was rehacked from the telnet code to make
it 8-bit clean and faster.

More time passed, and what is in progress now is an enhanced trf command
which overcomes the problem of 256-char message limits.  It takes one
or more send parameters and optional receive parameters.  The send
parameters can be strings (GET /foo/bar.html HTTP/V1.0), file names or
file handles.  The optional receive parameters can be file names or handles;
if no receive parameter is given then a scrap file is used as before.
If there is more than one receive parameter then auto splitting occurs
at blank lines until you run out of receive parameters (an HTTP GET with
one receive parameter puts the header and body in one file; with two
receive parameters the header goes in one file and the body, even if it
contains blank lines, in the second; with three the header goes in the
first, the body up to the first blank line goes in the second, the body
after the first blank line goes in the third).  Work is in hand to allow
pipes to be used instead of files, so an IRC client could pass two pipes
as send and receive parameters.

So, it's not a full sockets interface (anything but, in fact) and I suspect
it would be completely infeasible under DOS.  You might be able to shove
something like it in the Windows version though.  However, the Arc
conversion is from very ancient sources and the guts of the stack seem to be
very different.

--Paul