Re: RFA: Deprecate remote protocol sequence-ID

[Steven Johnson <sbjohnson at ozemail dot com dot au>]

Is it just me, or does there seem to be a fair amount of interest in 
creating a new and improved transport layer for the GDB Remote Protocol?

If this happens, then might I make a few suggestions.

1. Don't Re-invent the wheel. There are quite a few good existing async
transport layers
   that can be used as a basis. (Preferably one that can send binary
data.) 
   Async HDLC and DDCMP spring to mind.
   - Personally I prefer DDCMP to Async HDLC as it doesn't need to
escape binary data, and
     so makes writing a stub easier. (But it has a fixed message
overhead of 10 bytes).
2. We shouldn't get "anal" about a particular transport layer that the
new one is based on
   and should be willing to make minor modifications to ease the desired
goal.
3. Build in recoverability from the ground up. Don't make it optional.
i.e., every message
   has a message number (in both directions).
4. Add Compression to the packet data (in both directions.)
5. I Think the function codes and packet data should remain the same as
they are now.
   And yes, rule off the old protocol sand add advanced features to the
new one.
   (Maybe only bring over some messages from the old protocol to the new
one that are
    relevant anymore and drop all the deprecated ones.)

This is all motherhood stuff, but I think it is important to start
stating some of
the obvious stuff so that it doesn't get ignored. Anything else Ive
forgotten here?

Steven.