Subj : Something new...
To : Richard Webb
From : mark lewis
Date : Sat Oct 17 2009 09:25 pm
ml> ugh... i really do like FD's nodelist compiling stuff... all FD does
ml> is generate b-tree indexes on the nodelist and then if there are
ml> overrides for any nodes, those go into the b-tree index so they are
ml> used instead of the default nodelist data... with FD being able to
ml> use environment variables for nodelist entries, one simply replaces
ml> the phone number with the environment variable and then the mailer
ml> (FD) looks to the environment variable for the number to use...
RW> YOu're not using the raw nodelist with bt, at least with
RW> version 7. IT creates its indexes it needs.
right but the question is if the raw nodelist is still required to be in place
after the indexes are created or will the mailer operate with only the
indexes??
RW> Substitution of number to dial or node's flags is easy, at
RW> least in xlaxnode or tbbsnc. Just put it in the control
RW> file. WAnt to use the flags or dial number from the raw
RW> nodelist as is, just comment that line out of your control
RW> file, and recompile.
right... nothing different there...
RW> When I was feeding Daryl Stout for awhile last summer before he got
RW> everything squared away I was substituting and
RW> stuffing his pots number into my nodelist.
:)
ml> if i have stuff for a node that has both POTS and FTN over telnet,
ml> and i want to "crash" (i use immediate instead of crash) what i have
ml> waiting for them via POTS, i simply go to one of the POTS nodes,
ml> look at that mailer's outboud queue and change the flavor of that
ml> destination system's bundle(s) from hold to "normal", "crash" or
ml> "immediate"... all the other nodes still retain their settings for
ml> that destination... the one mailer node then does the connection and
ml> signals the others when it is successful so they will rescan and
ml> rebuild their outbound control files... i don't have to shut down
ml> all the mailers, take the few minutes to recompile the nodelist and
ml> restart all the mailers...
RW> YEp, can see that. I don't think squish uses flavors such
RW> as immediate and direct the way dynamic mailers do however.
RW> OF course, with bink you've got one set of outbounds as
RW> well between all nodes. so, the only thing other binkleys
RW> need to be aware of is that you're connected on a certain
RW> node.
right... i was just being a bit more specific...
FWIW: for FD, it treats CRASH mail differently than IMMEDIATE mail... CRASH
means go as soon as possible (and may include "directly to the destination
site") whereas IMMEDIATE means "go right now, no matter what the schedule is
set for... the DIRECT bit /can/ also come into play and it indicates that it
should go directly to the destination whereas CRASH and IMMEDIATE may not...
RW> Everybody still communicates between themselves with busy
RW> flags in the appropriate directory <g>.
yup... things can be done a bit differently by using memory semaphore or
conversation in an ICA (intra-communications area) but it is harder to work
with, to a point, and is not as easy as simply creating a "flag" file on the
disk... using an ICA or another memory type area doesn't use any disk space at
all... that may be a good thing in some situations...
RW> TWo ways of going about the same thing.
yup!
RW> Most nodelist compilers that create a nodelist binkley can
RW> use will let you do the above quite handily iirc.
ml> i'm sure ;)
RW> YEp, quite easy. AS I noted xlaxnode's fairly easy, and I"m sure
RW> fastlst and qnode were as well. I think some still use fastlst,
RW> but I haven't heard anybody mention qnode in years
RW> <g>.
yeah, i dunno anymore...
RW> <snip>
RW> YEp, similar. YOur tosser and other utilities build the
RW> *.*lo files. There will be a file in my outbound when I
RW> write this message created/updated by squish with a file
RW> name of 0e32000c.clo detailing paths and filenames to be
RW> sent to you.
ml> right... and there's the main difference... there's only one ?lo
ml> file for all the mailer nodes to see and use... it cannot be a hlo,
ml> flo and clo all at the same time so that individual mailer nodes can
ml> act on it the way they need to...
RW> NOpe, that's why you manipulate the information available to those
RW> nodes such as MIke Tripp and I both described. hE
RW> detailed another method using the cost field.
yes, that is another way but it is not optimal nor is it conducive to dynamic
changes that may need to be made on the fly without having to goof around with
the nodelist and its indexes...
RW> <snip again>
RW> When I helped a friend get it all going I referred to things I'd
RW> seen in this echo quite a bit, but that was way back in the day
RW> <g>.
ml> as was with many echos in fidonet, there was a huge amount of
ml> information on almost any subject that traveled between all of our
ml> systems... it really is sad that folk have folked to the internet
ml> for eye-candy without the real meat of the meal...
RW> INdeed it is. I really enjoyed turning newbies onto it as
RW> well. iT was fun to see the light come on when they figured out
RW> how just plain useful it could be.
in more ways than one, too! i remember a time when there were many businesses
using fidonet style technology for their communications capabilities... many of
the traveling salesmen were set up as point systems and used a mailer to send
and receive their orders and such... even a lot of tech support by those
companies was done via FTN methods... much of this is now done via mailing
lists or web based forum software... but none of that will ever touch all of
the capabilities that the old methods offered...