[nos-bbs] The UPLOAD command in sysop and user meu

[Barry Siegfried]

["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:

> > Let's say I am in a system console client session that is connected
> > to my favorite Net/Rom node.  I would like to sysop the node, reset
> > it and then connect again to load my initialization parameters.
> > Instead of typing all the initialization parameters manually, I can
> > instead have them stored in a file which I can then 'upload' to that
> > client session.  The Net/Rom node command processor will receive them
> > line by line from my client connection and assign the values I want
> > to use for node initialization.
>
> The example makes sense and my initial testing went well.

Good.

> Except for the "*" to mark active session - it was missing here.

That's odd.  I am quite sure that was already in JNOS.  I didn't
"invent" that.  Unless somebody removed it from JNOS?

> In *my* words - the UPLOAD command serves the same function as the
> SOURCE command:  the SOURCE command is applied locally and UPLOAD
> is applied to the active remote host session.

It's a stretch, but ok.  The reason it is a stretch is because this
*is* 'source's only function... that is, to apply local commands
from a file.  But 'upload' can be used for sending any kind of
ASCII data across a terminal connection.  The example I chose just
happened to be one that involves commands for a "remote" device to
which I am connected, but there are certainly more uses for 'upload'
than just that.

> I'm beginning to think my initial thought about UPLOAD has a
> little merit.
> Instead of trashing UPLOAD...
> "UPLOAD <file>" should be replaced with "SOURCE <file> [<session #>]"
> syntax.
> Because UPLOAD *should have* a <session #> parameter to remove
> ambiguity the work might be the same.

Go ahead and program it if you really need a <session #> parm.  I
don't need it so I wouldn't bother with it.  'upload' works fine
for me without it.

> Before you nail me on the missing <session #>, consider doing your
> example to two remotes simultaneously.

You really can't do that.  Only one session can be 'current' at a
time.

> Nothing about session structure prevents simultaneous remote connects.

No, of course it doesn't... but conversely, nothing about session
structure permits sending the same data simultaneously to more than
one session.  Just how would you do that?

> That makes a lot more sense to me at this moment...
>
> Actually - I *might* be wrong about simultaneous sessions if they are
> *active* and receiving packets from more than one source...  More later.

Sessions don't have to be 'active' (you really mean 'current') to
receive packets.  Received data in sessions which are not 'current'
gets tucked away nicely in input stream socket receive queues until
the session is made current and the data can spill out to the 'user'
in the session screen.

73, de Barry, K2MF >>
           o
          <|>      Barry Siegfried
+---------/-\---------------------------+
| Internet | bgs at mfnos.net              |
| HomePage | http://www.mfnos.net/~bgs  |
+----------+----------------------------+
| Amprnet  | k2mf at k2mf.ampr.org         |
| PBBS     | k2mf at k2ge.#cnj.nj.usa.noam |
+----------+----------------------------+