[dcc2] Final connection negotiation changes (WAS: Is DCC2 Dead?)

[myndzi]

Um yeah, I was just talking. No need to jump all over me eh?

I didn't really like appending the version number to the CTCP name
because not only does it look silly, but instead of the client knowing
it's a DCC request that it can't handle and responding appropriately,
it doesn't know anything at all if you change the CTCP name. I'd
rather leave a space and require the version as a numeric value
following 'DCC' or some such. "DCC2 1.0" would take all of ... 4 extra
bytes?

Furthermore, I did not mention anything about *how* to supply the
version token or anything else. I'm not "assuming the definition of a
token" or any such. I'm just brainstorming.

Speaking of which, of all the ideas I've posted here, nobody pretty
much concluded anything one way or another about them. I'd have to
look back over the archives but I nothing really sticks in my mind. If
this kind of snotty reply is all I can expect for direct feedback then
go ahead and count me out.


On Wed, 5 Jan 2005 12:24:19 -0500, codemastr <codemstr at ptd.net> wrote:
> 
> > Why not just have a version token, and set the defaults per version.
> > Whenever IPv6 does come around, inc the version a little and define
> > new defaults. You could perhaps specify a reply for 'max version
> > supported' as an error, in which case the sending client can roll back
> > to an earlier version. In any case, a version token is probably
> > useful, so that in the future any changes won't have to be by way of
> > defining an entirely new CTCP message etc., as DCC2 has done vs
> > DCC1...
> 
> I disagree. I think we already have a versioning system, the one you just
> mentioned, changing the number in the CTCP. Creating a Version token won't
> conserve bandwidth, it will only waste it (I now have to specify a Version
> token). The DCC CTCP has a builtin version system DCCN. If we create a new
> version, then it is DCC3. This is superior to your proposal in everyway.
> Your proposal requires a fixed order (Version= must be the first token in
> order to ensure that the parameters of the message are interpreted
> correctly). And your method is going to use more bandwidth. You want to add
> a new token, even if we shorten it as much as possible to say, V=N, that's
> still 4 bytes more (trailing space) than my proposal will use. So I don't
> see any benefit to adding a new token as opposed to just increasing the
> number after DCC. Yeah, for something like this, where all we are changing
> is default values, a new token isn't a bad idea. But, for bigger things,
> it's bad. You're assuming that DCC2 v1.0s definition of "a token" will be
> the same as v2.0s, which is a bad assumption to make. The whole purpose of
> having a versioning system is because you can add new features that break
> compatibility. For example, what happens if, for example, version 2.0
> decides that  : makes a better name/value separator than = does (unlikely).
> Your versioning system no longer works (v1.0 requires "V=2 ..." v2.0
> requires "V:2 ..." changing it from DCC2 to DCC3, on the otherhand, would
> handle this flawlessly.
> 
> -- codemastr
> 
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2
>