Re: alternative DateTime (ref: fts-0001.016)
  By: Maurice Kinal to Rob Swindell on Sun Dec 20 2020 01:49 am

 > Hey Rob!
 >
 >  RS> I guess you don't know what "backwards compatible" means.
 >
 > I guess the same about you.
 >
 >  RS> Backwards compatible means it would continue to work with
 >  RS> existing systems.
 >
 > I swear that is known simply as compatibilty.  Backwards implies the past.
 > However in both cases it is obvious the software we're using is {,backwards}
 > compatible given our exchanges.

Backwards compatible means enhancing/fixing functionality *without* impacting
interoparability with old systems that lack the enhancement or fix.

 >  RS> I suspect most other echomail programs would do the same.
 >
 > Mine as well.  However mine can quicky adapt to a much needed change in
 > order to facillitate progress especially when it concerns an obviously
 > needed fix. Your proposal doesn't allow for a proper fix and solves nothing.
 > Mine does and is therefore superior as well as much needed.

I haven't really proposed anything, but if I were, it would be a new control
paragraph (kludge line) in the variable length portion of the packed-message.
This would have no impact on older/existing systems and yet would allow newer
systems to utilize the more precise date/time information if they wished.

Control paragraphs are how new features have been introduced into FidoNet for
decades without breaking backward compatibility. This is the way.

 >  RS> Is this how you normally engage in technical discussions?
 >
 > I thought it was obvious that I don't normally engage in technical
 > discussions. Regarding this one I believe I am 100% correct and you are 100%
 > wrong.

Huh. So you agree that existing FTN systems would break if the rest of the
network were to switch to a new date format in packets, yet you don't consider
that breaking backwards compatibility. And I'm the one that's wrong? I can't
tell if you're joking, but I hope so. :-)
--- SBBSecho 3.11-Linux