I agree with Brian’s points on this. The specific issue isn’t the
modification of the data, it’s the lack of user visibility and
control. My suggestion would be to make it a checkbox that’s
enabled
by default.
Gary Weber <[email protected]> writes:
Okay, interesting point. During a download of a .DO file,
TELCOM
intercepts an <EOF> and prohibits it from from getting written
into the
file system. Sounds like you would argue that this is wrong
as well?
On Tue, Feb 12, 2019 at 10:35 PM Brian White
<[email protected]> wrote:
You said just one any one example, which I already gave, but
here's
another for free.
I try to write a checksum calculator, and I spend a million
hours trying
to get the assembly or forth working right, but no matter what,
the numbers
just never ever come out...
On Wed, Feb 13, 2019, 12:27 AM Brian White <[email protected]
wrote:
That places the obligation on the wrong party.
This is computers not inpressionist art. If I am trying to
figure out why
something is, or is not working, or document something by
experiment, it's
wrong to have a low level tool responsible for handling data
do something,
*especially* without notice or configurability, like modify
the data as it
passes from point A to point B.
If I have a file, that has some garbage data in it that is
actually
invalid, but it works *anyway*, because one of the tools I
just happened to
use did some clean up for me, then I now think I know what the
correct data
is. I just "proved" it because it worked. Meanwhile, it's
actually bad
data, and doesn't work in any other context. It wouldn't work
on a real
disk, or on any other emulator or device that didn't happen to
have the
same *backwards* idea about being "helpful". But I, not
knowing any better,
tried something, it worked, I wrote it all up on a web site,
provided a
download archive of all bad files, and years later someone
else spends all
day banging their head against the wall and throwing away
their "broken"
vintage machine because it isn't working... (In case we are
not all up to
speed, this is a hypothetical. I am not saying I actually did
this as was
so mystified and produced a load of bad files. You asked for
an example.)
In the last 20 years as a sysadmin, programmer, all around IT
analyst
dealing with all kinds of boring back-end integration
projects; that
feature of the "venerable" ftp has only ever caused grief and
cost time and
money over and over again.
The reasons it's wrong to modify your payload unless that is
your actual
explicitly declared purpose is to *process* it in some way,
are open-ended
and infinite. You can't know the possible reasons or
situations which might
ever come up with the countless possible users in their
countless possible
contexts in the open-ended future years. But you don't have
to. All you
have to know is that if you don't make any assumptions, then
you don't have
to worry about breaking them, or failing to think of
everything.
Any example will by definition be a contrived example, which
is too
tempting (for some) to disregard. Any contrived example just
sounds like
some unlikely thing that isn't important to worry about.
whatever the
example is, you just say "oh that's all? who would do that?
just don't do
that, that's all"
It's user-hostile, even if intending to be the opposite. It's
a misguided
concept of being helpful.
On Tue, Feb 12, 2019, 10:08 PM Gary Weber <[email protected]
wrote:
Brian, describe ANY scenario at all, where cleansing trailing
<EOF>
characters from transmitted .DO files into a Model T file
system, is a
wrong idea. I'm genuinely interested. :)
On Tue, Feb 12, 2019 at 7:28 PM Brian White
<[email protected]> wrote:
I referenced ftp as the canonical *anti-example* in my first
comment
and then again later.
It proves how wrong the idea is, not how right it is.
On Tue, Feb 12, 2019, 6:53 PM Gary L Phillips
<[email protected] wrote:
I'll just add one small note here.
No less venerable a program than ftp, as implemented on
dozens of
environments, makes changes to data being transferred. It
does so by
default and without warning, to adjust text files from one
system standard
to another. The obvious case here is automatic conversion
of line endings
between CR (as used by many early microcomputer systems,)
LF (as used by
most *NIX compatibles and Apple systems,) or CR/LF (as used
by PCDOS and
MS-DOS.)
And yes, this does sometimes cause corruption or confusion
when binary
data is transferred, unless the user specifies that the
data is binary and
to be left untouched.
Gary Phillips 😉
--
Gary Weber
[email protected]
