Re: Remote protocol and 7-bit links

[Steven Johnson <sjohnson@sakuraindustries.com>]

As a remote protocol user I say:

Bring on 8 bit only.  I haven't seen or used a UART that cant be set
into 8 bits per byte since I started using them (late 80's).  Its 2006,
cant we deprecate the requirement for everything to be 7 bit clean, and
just assume 8 bits is the way?  Architectures get obsoleted faster than
the requirement for everything to be 7 bit clean.  Hex encoding stuff
just adds work and makes life harder for the stub.

As a minimum, I would say these new features be 8 bit only, and then 7
bit hobbled targets (if any actually exist) cant use them.

Steven J


Daniel Jacobowitz wrote:

>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?
>
>  
>