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!”

3 Responses to Look around for more space to escape

  1. flow84 says:

    Is it not better to have a char that looks like a space but isn’t a space in protocol spec?

    For splitting that is.

    I mean. Then all clients and hubs doesn’t need to replace the space to something else every time and you will still have 1 char length and not 2.

  2. Fredrik Ullner says:

    It could be done like that, sure.

    I don’t consider either solution as “better”. Space is a delimiter character. We might as well use a different character if space would treated as a visual space. Like $ or whatnot…

    Personally, I’d rather leave it as it is since it would be slightly more annoying to code…

  3. djoffset says:

    So, how about using “,” for delimiting command arguments.

    HSUP,ADBASE
    BMSG,,Hello\,what’s up?

    Arguably you will see fewer commas than spaces in text messages, and
    very few in file names since Windows don’t like them.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: