Remote protocol and 7-bit links

[Daniel Jacobowitz <drow at false dot org>]

Now that we've shaken the branches a little and found that there are at
least a couple users of the remote protocol on this list...

Are any of you using links to targets which are not 8-bit clean?  The remote
protocol, as currently defined, is strictly 7-bit with the exception of the
optional 'X' packet.  I have two projects which I'll be submitting in the
near future which involve transmission of large amounts of data:

1.  Self-describing targets return hefty XML blobs.

2.  Remote file upload/download transfer, well, files.

And I don't really want to hex encode all of this stuff if I don't have to.
A lot of remote protocol users use TCP or UDP, which obviously can handle
8-bit data.  Many also use serial devices; all the ones I've used (over the
last ~ six years) have been eight bit clean, even when terminal servers were
involved.

If this is going to be a problem, I could implement binary and non-binary
variants, or use some other mechanism to switch between.  But I think that
eight bits per byte and a clean link layer which won't get too upset by
NULs are reasonable things to assume in the 21st century.  And even in the
previous decade; any terminal server that can't handle eight bits can't
handle PPP...

I'm not suggesting to change the format of any existing packet, and the new
packets I'll be adding are optional.  So this wouldn't impact simplistic
stubs that don't need the new functionality (and even most descriptions for
the self-describing targets won't have 8-bit data in them).  But 8-bit
support would be necessary if you wanted to support the new features.

Any opinions, or counterexamples?

-- 
Daniel Jacobowitz
CodeSourcery