TIP: Click on subject to list as thread! ANSI
echo: ftsc_public
to: MICHIEL VAN DER VLIST
from: MARK LEWIS
date: 2014-10-05 12:13:00
subject: FTSC-5001 question

 On Sun, 05 Oct 2014, Michiel van der Vlist wrote to mark lewis:

 MvdV> when the INA flag came into the picture over a decade ago, I 
 MvdV> proposed  having protocol flags inherit information from those 
 MvdV> preceding them as an alternative. 

i remember... the problem with that is how to indicate a "no capability"...

in the rewrite of the example i gave, you ended up listing the final backup
system as the main connection and that is not how that connection's entity was
designed... it would be like listing three MXes and having everyone send to the
last backup instead of to the main one... yes, the example given was on the
""extreme"" end of the belt but it showed how explicitly listing and ordering
of the flags can be used so that one can set their systems they way they
want/need them to operate instead of being forced to operate in the way that
others tell them to operate... many drop out because of things like this that
can't be resolved to suit their needs...

 MvdV> That was voted out/shouted down/ignored as well. Instead the
 MvdV> system continued into one where flag meaning does not depend on
 MvdV> order.

i never saw that... what i saw was positional usage which was promoted more
with the multiple INA flags capabilities...

 MvdV> That happens, one can not always get the system to adopt what 
 MvdV> one thinks is the best way. 

true...

)\/(ark

* Origin: (1:3634/12)

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.