home bbs files messages ]

Just a sample of the Echomail archive

<< oldest | < older | list | newer > | newest >> ]

 Message 45 
 Terry Roati to Mark Lewis 
 RE: Linking 
 04 Jan 22 22:31:58 
 
TID: PX/Win v7.0 PX96-0649M
MSGID: 3:640/1321 EF0D56A4
TZUTC: 1000
All,

The question is what echo areas are the BACKBONE, BACKBONE.NA has not been
updated in years? I still see some old backbone areas are still active so I
use them and the ELIST echos.

Other echos like Usenet I keep in a seperate file.

Presently I have all the STAR nodes connected to what I think is the backbone
echos only but they have access to AREAFIX others echos.

Please let me know if this needs to change.

Thanks,

Terry

On Jan 04, 2022 07:20am, Mark Lewis wrote to Dallas Hinton:

 ML>  On 2022 Jan 03 16:48:38, you wrote to All:

 DH>> I propose connecting all of you (except zcs) to all my file and
 DH>> echomail
 DH>> areas, both send and receive. That should, I think, achieve redundancy
 DH>> to/from my system, and I'd presume you'll do the same?

 ML> i'm not sure i understand this... hopefully it is not what was done
 ML> such that any and all areas are added to all the stars...

 ML> my thinking is that as backbone stars, we should only be auto-connecting
 ML> backbone areas *if* any auto-connecting is done at all... but i believe
 ML> it is best for there to be no auto-connecting... this gives each star
 ML> operator the chance to properly prepare their system for newly added
 ML> areas and then they can areafix the areas on with each of the other
 ML> stars they are linked to... this also allows each operator to properly
 ML> restrict certain areas if needed... auto-adding areas at will allows
 ML> for areas with restricted access to be leaked and we certainly don't
 ML> want that... of course, the default auto-add could be that all areas
 ML> are initially restricted but then the operator has more work to do to
 ML> unrestrict them...

 ML> we certainly don't want to see complaints from other star operators
 ML> when they need to unareafix 250+ unwanted (eg:) newsgroups (like i had
 ML> to do the other day) that are not carried on the backbone... any star
 ML> system /can/ carry those areas if they want to but that doesn't mean
 ML> those areas are /on/ the backbone...

 ML> being a star system carries a responsibility but that responsibility is
 ML> only for the areas /on/ the backbone...

 ML> being "on the backbone" is defined as "listed in the distributed
 ML> backbone.na file"...

 ML> NOTE: above, i'm only talking about echomail areas... the filebone is a
 ML> different matter but has similar needs in that operators need to
 ML> properly prepare their systems for the storage of the files carried...
 ML> even if it is temporary storage until the files are fully distributed
 ML> to their links...

 ML> )\/(ark

 ML> "The soul of a small kitten in the body of a mighty dragon. Look on my
 ML> majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh,
 ML> a shiny thing!" ... GOD thinks he is a mathematician, but actually he
 ML> is just an engineer. ---
 ML>  * Origin:  (1:3634/12.73)

... Platinum Xpress & Wildcat!..... Nice!!!!
--- Platinum Xpress/Win/WINServer v7.0
 * Origin: The File Bank BBS! https://tfb-bbs.org (3:640/1321)
SEEN-BY: 153/7715 229/426 250/1 275/100 640/1321 3634/12
PATH: 640/1321 153/7715 229/426


<< oldest | < older | list | newer > | newest >> ]

(c) 1994,  bbs@darkrealms.ca