Subj : Another filearea question
To   : Mark Lewis
From : Mvan Le
Date : Sat Jun 09 2007 12:41 pm

ml>  MvanL> Man I just use the Hurl menu option.

ml> what has that to do with removing fossil and door
ml> library code from the package in question? hurl is used
ml> to move a file from one location to another along with
ml> its description... that has nothing to do with the
ml> original question and discussion about MFM importing file_id.diz files...

Hurl has everything to do with not removing fossil, library code and importing
file_id.diz's with the package in the original question and discussion.

ml>  MLvan>> copy %max%\dorinfo1.def .\dorinfo%1.def

ml> that is exactly how one does it with a system that
ml> doesn't create dorinfo2-9 files... now, what does one
ml> do when they are running 10 or more nodes? the

Pass the node as an argument to the door. If the door doesn't support such
execution then use an alternate dropfile.

ml> dorinfox.def standard wasn't thought thru very well...

People assuming that "x" is a node designator would be uncomfortable with their
understanding of dorinfo1.def.

ml> i've seen implementation that use hex and as such can
ml> support up to 16 nodes... i've also seen
ml> implementations that support base36 which is also
ml> limiting on a large multinode system... then, there're
ml> those that start dropping letters to make room for numbers...

ml>   ie: dorinfo1.def
ml>       dorinf22.def
ml>       dorin134.def

Which is all pointless unless the door is programmed to read the most recent
created *.def file or accept a node number as a command line option.

A "/node=65535" sounds pretty limitless to me.

ml> like i say, not very well thought out... but it is way
ml> way way too late to do anything about it now, too... i
ml> tried some 15 years back but all anyone wanted to do
ml> then was spout the existing standard and do nothing
ml> about fixing or enhancing it...

... assuming it needed fixing or enhancing. That's what alternate dropfiles
were for eg. door.sys.

Did you ever think dorinfo1.def was made for Maximus/QBBS/RBBS, and that doors
written for these systems were meant to follow a standard method of execution
ie. support a /n# or /node= et al. ? and/or interface with their respective
BBS's in a certain way ... The same way(s) exitinfo works for RA and forces all
RA util authors to adhere to its ideologies, and prevents other BBS's from
using exitinfo-specific doors ?

ml> [trim]

ml>  MvanL>> Apparently people adopted the numeral in dorinfo#.def to
ml>  MvanL>> be a node designator when it was never meant to be. It's
ml>  MLvan>> probably a "dorinfo" dropfile specification version number.

ml> hunh? you can provide documentation to this? i'd like
ml> to read it because nothing like it was ever presented
ml> or found in all my research years ago... everything i
ml> found showed that the number _was_ the node number...

Because that became the most popular train of thought.

It is documented somewhere - some BBS/door author(s) made a complaint.

ml> some bbs systems got around the 9 node limitation by
ml> creating dorinfo1.def for all nodes, though... and
ml> that's no real problem if the door can look in a
ml> directory other than its own for the drop file...

ml>   ie: somedoor c:\bbs\n1

ml> where c:\bbs\n1 is where the dropfile, whatever is
ml> being used, is located... c:\bbs\n42 for node 42... no
ml> copying or overwritting and no possibility of things
ml> going wonky if two users enter the door at the same time...

My argument would be people started writing and using TCP/IP and multithreaded
daemons and computer clusters and invented the I-n-t-e-r-n-e-t.

And that's why those large multinode BBS's are extinct and any node/dropfile
conflict issues are nowadays virtually impossible.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)