Look around for more space to escape

If people look at the previous post on escapes, they probably notice that we’re essentially “increasing” what is being sent in ADC to represent certain things. And of course, the NMDC advocates say that this is one of the reasons why ADC is worse and that NMDC is better.

Well, they’re correct in one part. We are increasing the bandwidth when we want to use certain characters. We will not get away from this. This is a fact, and I can’t dispute it.

I checked previous post for spaces. There were 329 of them. This mean that in NMDC, it would have been 329 characters to represent the spaces, and 658 characters to represent them in ADC. However, we know that while messages are a contributor to overall bandwidth, but there are far worse culprits.

On a different note, what would happen if we used a different character to represent the visual character of a space? Well, then we’d “get rid of” the escape sequence for a space. Eg, what if the client would replace, before sending the message, every normal space with a non-breaking space. The character would look like a normal space, and depending on how clients and hubs interpret characters, it wouldn’t be treated as a delimter.

I tried this with DC++ and ADCH++; It worked like a charm. Visually, the character appear as a normal space, and DC++ doesn’t attempt to encode it nor does ADCH++ choke. (The “annoying” thing is that if you enable AdcDebug, the output might throw you off.)

Also, there’s probably other characters that are visually a space, but are not actually one. If developers are afraid to use much bandwidth, you know what to do. (Yes, I can agree that this is an weird solution, but I believe it to be the only one. We should NOT introduce other things in ADC that would change command design.)

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”