On Wed, Oct 09, 2002 at 10:00:31AM +0200, Hannes Gredler wrote: > IMHO changing protocols/formats once code is shipping is clearly a thing > to avoid;
I.e., we can never ever ever introduce a new libpcap format to add new capabilities? I don't agree with that at all. It's not as if the new format would use the same magic number, so it's not as if you've changed *the* libpcap format, so that new programs can't read old files. (And as for never changing protocols, well, so much for NFSv3, NFSv4, and IPv6....) > the DLT_private type would fiz both problems at the expense of > a few extra bytes ... It "fixes" the problem of changing the file format by, in effect, changing the file format - if only the DLT_private type can have extensions, then only versions of libpcap that support the DLT_private type *and* applications that support it can handle files with extensions, which means that, for all intents and purposes, you've changed the file format (i.e., you've made a file format that older code can't read, which is the *ONLY* problem I see with introducing a second-generation libpcap format). - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
