Pre-Release and Secondary Areas
Tick 2.0 adds several enhancements, two of the most significant
of which are PRE-RELEASE and SECONDARY AREAS. These are more dif-
ficult to describe than to use. What follows is an attempt to explain
them.
A little historic background may be helpful. Back when the SDS
as we now know it got started, one of the ideas was that we could make
provision for software to be distributed within the SDS-RC structure
into each region before the official release date, so that when a
major release, such as a new Binkley came around, it would be readily
available everywhere at once on release day. This concept is PRE-
RELEASE. To date, the only implementation had been in FLEA. That
provided the ability to distribute a file throughout the network, but
would delay the toss to the downloadable directory until the official
release time. That was good so far as it went, but it made the as-
sumption that the SDS would consist of a small number of distribution
nodes, and that the net-level sysops would get the files by FREQing
from their regional SDS nodes. The SDS and other distribution net-
works developed in a different direction, however. In most cases the
net level nodes are directly linked into the networks, elimination the
need for FREQ entirely. This expansion rendered the simpler pre-
release method unworkable.
What was really needed was a method of limiting the distribution
of pre-released files to the core structure of the distribution net-
work, and to pass the files "down the pipe" on the release date.
hopefully, TICK should now make this possible.
When a file is hatched into an echo, it will now be possible to
specify a release delay of a certain number of days. The file will
immediately be sent only to those nodes which are designated as having
permission to receive pre-released files. Those nodes will likewise
send the file only to similarly privileged nodes. Until the time of
release, the files will reside in a special "quarantine" directory
(QDIR). When the release time arrives, the file will be tossed to its
destination directory, and sent to those nodes which have not yet
received it. This is the basic PRE-RELEASE concept.
SECONDARY AREAS is another added feature, which may be used inde-
pendently or in conjunction with pre-release. Presently, file echos
are defined with an echo tag, just as in echomail. It is now possible
to associate a secondary echo (carrying its own echo tag) with a
primary echo. In such a setup, any files hatched or received in the
secondary area would echo only in that area. Files hatched or
received in the primary area would echo in both primary and secondary
areas. For example: Someone recently mentioned in SOFTWARE that he
was receiving the new releases of "Remote Access" BBS directly from Oz
in an echo with the tag of RA_DIST (That's not the actual name, but it
1
will serve for now). He now has to manually alter the tag to
SOFTDIST to distribute it via SDS. If RA_DIST is set up as a primary
area, with SOFTDIST as its secondary area, he could receive the file
in RA_DIST, and distribute it in SOFTDIST automatically. Note that
the use of SOFTDIST as a secondary area of RA_DIST does not interfere
with its usual use, where it is defined as a primary area elsewhere in
the TIC.CFG file. Also note that echoing in SOFTDIST do not "flow
backwards" into RA_DIAT. A segment of a TIC.CFG with such a setup
follows:
Area c:\sds\softdist SOFTDIST
1:266/12 Password *C
2:512/26 Pass2 H
1:116/26 Lhz H
Area c:\sds\racess RACESS SOFTDIST
3:333/29 Pass3 *C
1:261/662 Pop *C
1:116/29 kjn C
In the above segment, files passed in SOFTDIST will echo as they
always have. They will NOT be echoed to 1:266/12 or to 2:512/26.
Files received in RACESS from 3:333/29 will be echoed to 1:261/662 and
1:116/29 as RACESS, and will be echoed to 1:266/12 and 2:512/26 as
SOFTDIST files. (1:116/29 will NOT receive files received in RACESS
as SOFTDIST file, because when the primary area is processed, his
seenby is added before the secondary area [SOFTDIST] is processed ...
He WILL receive files that were received in SOFTDIST as SOTFTDIST
files, however.)
Using Pre-Release and Secondary areas together
Although pre-release is independent of secondary areas, a good
use of the combination would provide additional security against the
premature distribution of a pre-released file. What I thought of
doing was this: Set up a primary area for each echo, and have use
those areas for pre-release files only. Each primary area would have
as a secondary area, the file echoes we all know and love. Files that
were not pre-release would be distributed in the usual echoes. Pre-
release files would travel in the pre-release echoes, and be released
into the normal echoes at release time. For example: SOFTDIST is
defined as a primary echo in one part of the TIC.CFG. PRESOFT is
defined as a primary echo in another part of the TIC.CFG, and has
SOFTDIST defined as a secondary area to it. Only authorized nodes
would be linked to PRESOFT, while the whole world is linked to
SOFTDIST. A pre-release file would be distributed by the SDS-RC
structure via PRESOFT, and on release date would be tossed into
SOFTDIST in each region simultaneously. By using the separate areas,
the chance of an unauthorized node inadvertently being sent a pre-
release file is reduced.
2
3