On Thu Jul 04, 1996 (23:19), Andrew Leary wrote about ZONE NUMBERS:



 AL> Since the extension cannot be more than three characters (on DOS FAT

 AL> file systems anyway), you cannot have an outbound for a zone greater

 AL> than 4095 (16^3-1).



     True.  Although, as I mentioned in my earlier note, you can kludge one
"high zone" into Binkley by making it your "primary
zone".  Since the primary zone doesn't use an extension, it's not
limited to numbers <= 4095.



     Now the question becomes, can we convince those who are working on
Binkley and related utilities (maybe the BT-XE team?) to come up with a
general way to handle zones > 4095?  Right off the top of my head, I can
think of at least three ways this could be done, without changing the
behavior of Binkley for zones 1-4095:



     1) For higher zones, use more characters in the extension.  This would
not work on normal DOS FAT, but it would work on most of the new OSes out
there. For example, OS/2 can easily do this with an HPFS drive. Ditto for
Win-95 and it's "long name support", or for that matter most UNIX
systems.  So about the only people that would be "out of luck"
with this approach are people using the normal DOS version of Binkley, and
even they would be no worse off then they currently are (ie they would
still be able to handle zones 1-4095).  This approach wouldn't put any
artificial limit on zone numbers, but since FTN packets limit zones to 64K
(or is it 32K?), then there is little point in going beyond 4 hex digits
for this approach....



     2) Another option is to limit outbound names to 7 characters.  If you
do this approach, you could put one hex digit on the end of the root
outbound name for zones 4095-65536 (and treat zones 1-4095 as we currently
do).  This approach should be fairly easy to implement, and it would also
work with DOS and FAT. About it's only limit is that you do lose one
character in the name of the outbound (very minor IMHO).  This would
probably be my first choice, since it's fairly simple and works on the
standard DOS 8.3 file system.



     3) Finally, you could always use the letters G-Z in the extensions.
This would change the logic from using hex to using "base 36".  A
little more confusing to many people (especially if you get fancy and only
use the letters G-Z for zones >4095) but it would allow you to encode
zone numbers up to 46655 into the three character extension.  FWIW I would
probably give this as my last choice, due to the fact that this
"standard" could easily confuse people.  OTOH it does make the
most efficient use of the character space you have in the filename.



     Of course, none of this is going to make any difference unless the
authors of Binkley (and later authors of other programs, for example
squish, that use the outbounds) decide on a standard for zones >4095 and
implement it.



     Hmmm....  Are the authors of BT-XE reading this message? Any chance of
putting in zone support for zones >4095?  IMHO the first approach to
dealing with this, is to have Binkley implement some "standard"
for this, and then let people know about it.  I would assume that once
Binkley has support for these "high zones", that other software
authors will slowly start to add this support into their code.  But if
Binkley doesn't take the lead here, then support for these upper zones will
probably never be implemented....



     Robert



--- timEd/2 1.10+