[nos-bbs] Re: xNOS Bugs!

[Barry Siegfried]

["George (Skip) VerDuin" <k8rra at ameritech.net> wrote
  on "BBS Download and Upload command bug"]:

> I guess I'll go on record with the BBS "Download" and "Upload"
> command failures as a bug too.

These are not bugs.  It is the way these commands were originally
written and if you need to call them anything, call them "incomplete".

> On my jnos2.0d the Download command lists the remote file on the
> terminal, no file is created in the local jnos file directory.

What would the name of this file be on the local machine?  What if
<path> of the [<path>]\<filename> spec for the file that you are
downloading from the remote system does not exist on your local
machine?  You would get a failure to write unless your command
*also* contained code to create <path> if it did not already
exist.  More code, larger program.  Is it worth it?

If anything, this command is *missing* a second specification to
locally name the file being received.  It was never written into
the program because this functionality of the PBBS part xNOS is
hardly used anymore (more on this below).  It is also what the
'record' command can be used for at the system prompt, to capture
input from a console session to a file.

> On my jnos2.0d the Upload command expects the user to enter the
> file content on the terminal, a file is created on the remote site.

Again, this can be views as simply "incomplete" and also what the
'upload' command at the system prompt can be used for at the system
prompt, to send output from a file to a console session.

> Before this situation is repaired per the documentation, I'd like
> to pose and alternative action.

It depends how you define "repaired".  The PBBS and services parts of
the xNOS programs are the most time- and memory-consuming parts of
them because they are full interactive applications and as such they
are expected to interface live to "users".

> As step #2 I propose addition of "get" and "put" commands exactly as
> applied in ftp, and again I will contribute the doc and help changes
> to support this approach.
>
> As step #3 other ftp commands might be implemented into the jnos BBS
> command structure?

All any of this takes is *more* code and less working memory.  The
real challenge is, where do you draw the line?  You can build all
sorts of "user functionality" into these parts of the program.  But
is it worth the cost in memory?

The real treasure of xNOS is not its applications or services, but
its ability to route packets and this it does with a simplicity that
is unequalled in any other O/S and a very high degree of reliability
if left alone to do just that.  By definition, xNOS cannot be everything
to everyone.  I said above that these commands are hardly used anymore
in any working copy of xNOS that I know of and that is because most
people who compile their own programs leave the #ifdefs for these
"features" #undefined since they take up lots of valuable memory as
they are which can be utilized more efficiently in other parts of the
program.

To my way of thinking, these kinds of commands are for "full-service"
PBBS functionality and if that is what you want, then you need to
run a "full-service" PBBS program and that certainly ISN'T xNOS.  :)

> As a final thought, file transfer seems to this author to be a worthy
> capability.

That is what FTP is for.  Putting FTP-like commands into the PBBS is
a crutch to help people NOT get used to using the more traditional
TCP/IP services.  The FTP client and server in xNOS are actually
pretty darned "fully featured".  :)

["George (Skip) VerDuin" <k8rra at ameritech.net> wrote
  on "JNOS pagination bug"]:

> I guess I need to go on record with the pagination failure as a
> bug.

Again, this is not a bug.  It is the way the "- More -" prompting
was originally written and if you want to call it anything, call
this "incomplete" as well.

> The XM command successfully adjusts the line count for page display
> control.  On my 2.0d and my friends 2.0a version of jnos, neither
> telnet nor ax.25 access to the BBS successfully paginate output.

I don't use JNOS but I would bet that they do.  They paginate output
for EMAIL functions of the PBBS part of the program which is where
they were originally designed to function.

> Command responses to IH or J continue to stream output until
> completion and do not pause at the XM line count.

That is correct.  These are not email, but rather "heard" functions
of the PBBS.  They use a socket printing method of output to the user
and do not keep track of line numbers, which is only done in the email
parts of the PBBS.

If you find that some output from a PBBS to one of your xNOS sessions
has more lines to it than your display is capable of handling then you
can 'record' it at the net> prompt and examine it "off-line" after
you close the file.  The system 'more' command WILL paginate output
to a console session.

> There are work-arounds for this so I'm not looking for a fast fix.
> But it seems worthy of being in the bug-fix list somewhere...

Again... this is NOT a bug.  All it takes is more code.  More code,
less working memory.  You have to ask yourself, what is more important
to you, having full "user functionality" or having a program with enough
working memory to do the really important things that xNOS was originally
designed to do?

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