> 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 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
