Known Linux quirks or buglets:
Now, if a user has DELEGATION on and tries to send a message to him/her self, the dosend(() function says, "nope!", tells the user why, and aborts the message. It is also logged in the log file.
[d] %file ....... ....... [d+1]where 'd' is the day of the month ([1], [2], etc.). The "%file" is optional. If you use it, the data for the quote is read INSTEAD from "file". The entire "file" (as much as 4K) is returned as the quote. If "file" is NOT included on the "[d]" line, all following lines (until the next "[d]" line) is returned as the quote.
A few have been added in the appropriate places and performance of the entire system has improved. Previously, a system would sometimes MYSTERIOUSLY become unstable, with plenty of memory, if the Conference Bridge became highly active. The mystery has been solved!
And so enters POOLED memory. The idea is this, instead of allocating dozens of little allocations, we will allocate a smaller number of LARGER allocations, in pools. Initially all pools will be allocated in multiples of 50, though this might become configurable at a later date. While this may sound large, the size of these individual components are about 20-30 bytes each, making a pool of 50 only 1K to 1.5K. There is no penalty, for example, for ax25 heard if you do not set up "ax25 hport"s, since the pool memory is not allocated until the first request comes in, or until the current pool is exhausted.
While this is not perfect, it SHOULD reduce memory fragmentation dramatically for these routines for most systems, without noticable overhead.
This cuts down on bandwidth for listings at peak times.
ProxyMail has been implimented as a Script, partly as an example, mostly because it is a simple task that can be handled WELL in a script, and it allows easy customization.
Other parts to the ProxyMail Trilogy (coming soon to a theater near you) are the parts to allow the user to set this information without SYSOP intervention (probably a script, also) and a part to allow a user to send a single message to the BBS giving areaname-messagenumber combinations which will generate a SINGLE message in reply, for easy "fetching".
For example,
~i2=~p (save current position) ....... (do something) ~sp 2 (later, return to beginning position)
Also now the following attributes of a parent script get inherited by a child script when using the "~$" command:
user I/O socket (this was previously the only inherited attribute) whether it was an IP connect or AX25 call sign of user, if AX25 all integer variables, and string variables all open connection sockets (they should NOT be closed by the child) (you WERE warned!) the current data file is NOT inherited, allowing the child to have a separate data file, without closing the parent's file
The syntax is "CMD cmdname arg0 arg1 arg2 ... arg9". All parameters are optional. If any arguments are given, they are passed to the script as string variables ~0-~9, and the number of user arguments passed to the script can be found in integer register ~i0.
~a 1 /nos/scripts/ # directory name in 1 ~a 2 .cnf # file extension in 2 ~ap 1 9 # add the basename to 1 ~ap 1 2 # and add the extension to 1
This is necessary since the ~f and ~o commands either take a hardcoded string, or a single variable (i.e., "~o ~1", in this example).
NOT YET COMPLETE... MAY BE HELD OFF TO RELEASE 1.11
You might already be asking "WHY!" (or be dialing 1-800-KILL-KO4KS). Let me give you two different VALID uses to rewrite the from, especially at a gateway.
1) I run a Linux system, with TNOS/Linux running on the same machine. For some DUMB reason, I prefer using a REAL mail program than the BBS mailer. On the Linux system, I am "brian@lantz.com". I want to respond to mail, sent from regular PBBS, which has been forwarded to my "brian" account. BUT I want it to be FROM "ko4ks@ko4ks.ampr.org". This addresses that need.
2) A gateway can provide Internet addresses now, and the mail can even be forwarded to other non-IP BBSs, if that is desired. BUT if the user sends mail, it MUST be sent from an IP BBS that is known from the Internet. With translate, the user can send from a non-IP home BBS (if arrangments have been made with the IP sysop), and have that mail TRANSLATED to look like it was coming from the Internet-known IP BBS. That sysop COULD set up a forward.bbs entry for that user that rewrites the TO address to the one expected by the non-IP BBS, and voila! Two way Internet traffic with a non-IP endpoint.
Return to the Upgrading TNOS
overview.