Ok, I'm totally crammed for time for the next few weeks so I'm going to keep
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
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
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
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
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 -