Re: A few potential requirements

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

The following seems to me to be an example of the religious issue of
text vs binary as the format for application layer messages. Some
people believe that text is just wonderful because you can easily
generate it with all sorts of tools (even printfs in C) and you
can process it with all sorts of tools (like CVS, diff, etc).
And if the text is in your native language and uses your character
encoding (US ASCII for most of use, and not EBCDIC), then you
can read it and generate it easily. If  the message format is
in some binary encoding, then you need programs/libraries to
encode and decode it. Due to past experiences, the libraries
always seem to have bugs, which are difficult to track down
and isolate.
On the binary side, the pluses are the efficiencies of the bits
on the wire, the efficiencies of not having to convert from
internal binary format to text and back to binary. The "precision"
of the specifications (you don't have questions like, does a line
end in a CR, a CR/LF, a LF). CPU and buffer usage do matter on
the managed devices (as well as the bits on the wire), and the
conversion to/from text can be easily done on the manager side
with decent programs/libraries. The Text group is just over
reacting to a few bad designs and/or implementations using
a binary encoding.

I can argue either side - done both, several times. I bet others
have also.

At 02:20 PM 6/26/2001 -0700, you wrote:
>Tue, Jun 26, 2001 at 05:02:07PM -0400, Jon Saperia:
>> 
>> This is getting to the point I am attempting to understand. Being
>> able to diff configs and config changes is clearly important. I
>> do not see how the method of how the configuration changes or the
>> entire configuration 'data set' got to the box matter. You want
>> to be able to verify what was sent - to see what is there in
>> whole or part.
>
>the bits on the wire matter if one is trying write libs/whatever to
>handle it; assuming there are no libraries, no free libs, or no
>satisfactorily functioning libs.  i also need to have the supporting
>"applications" on my mgmt box; which doesnt have uucp-over-tcp.
>
>i think everyone agrees that we dont want bits hidden or out of reach.
>one of the advantages that makes unix paramount (besides the lack of
>the daily reboot feature); let me do what i want, even if that results
>in decapitation.
>
>i dont understand why you want any bits to be hidden/off limits.

Regards,
/david t. perkins