Ok, I'm totally crammed for time for the next few weeks so I'm going to keep this short.

The DC protocol is not extensible enough. That was a mistake on my part. I was young, and didn't give it enough thought. I'd never done anything like that before - I was 17.

That said, I think it would be ugly to add a bunch of messages that rely on some kind of $Support or $Key hacking, and that clients would easily mess it up.

I would prefer a totally different message encoding. That was of a regular format. And the hub+client would agree at connection time if they would use the old encoding method or the new one. This way it would be backwards compatible. All hubs would support both methods.

The message encoding might look something like
<command>:<argument>:<argument>:<argument>
where <argument> was \ escaped to protect from internal | or :'s and command was defined to never contain : or |. This way, you could always read a block of bytes into a list/array of arguments with the same decoding rules.

Further more, I think that it should be UTF8 rather than Windows encoded text.

Also, no hub should only provide the new encoding, and there must be a one to one mapping of all the basic messages. So, client developers would be able to support it easily. For example, I should NOT have to edit the code that acts on or generates a message, but should have to edit the code that encodes/decodes messages.

So, I don't want a new 'protocol' but I do want a new encoding scheme, and I would like to add new messages, but all old messages should retain their meaning.

Requirements would be
    - EVERY hub that supports the new encoding scheme MUST support
      the old scheme
    - Every message is encoded/decoded with the same set of rules
    - No binary values
    - One-to-one mapping from old messages to new messages
    - One protocol addition. A new message 'Supports' that identifies
      the commands a client supports sent immediately after it is decided
      that the new encoding method is being used.

So in the end, I would really prefer a new encoding scheme with a defined way of extending it (supports).

But if you want to make a whole new protocol, I think you need to make a whole set of applications, and call them something besides 'Direct Connect'

One last, requirement. Don't use a name like keywords like JONSEXTENTION or NMDC2EX or BCDCNewProto or anything, keep it client agnostic. :p

Thanks Guys -
Jon Hess