| |
KB2VXA > INFO 27.08.02 03:16l 35 Lines 1570 Bytes #999 (0) @ WW
BID : 55625_WT3V
Read: DB0FHN GUEST
Subj: Re: G0TEZ > Deja WHO?
Path: DB0FHN<DB0ZWI<DB0MAB<DB0FBG<DB0TUD<DB0GRL<SR6BBA<OK0PCC<OK0PPR<OK0PPL<
RZ6HXA<SP7MGD<WB0TAX<KB2TXP<KB2FAF<KB3BIU<WA3LWR<W2LV<KB2VLX<KC2COJ<
WT3V
Sent: 020826/2255Z @:WT3V.#JS.NJ.USA.NOAM #:55625 [Lakehurst] $:55625_WT3V
From: KB2VXA@WT3V.#JS.NJ.USA.NOAM
To : INFO@WW
Hello Ian,
WOAH! How, hold on there padnah! What's wrong with this (7+) picture? You
say that I sad that such files should be sent over the Internet, right,
but only in PART. What you left out was my saying LARGE, multi part files
should be AND that the purpose would be better served thereby. Now let's
not compare apples to oranges, images to text, being the file size bears
no comparison. Let's not bit pick either, when all the parts are
compiled, the file is huge. No matter how many parts it is split into,
the total sent is the same.
I seem to be having a case of Deja Vu myself, repeating myself for those
who haven't been paying attention. The beef is, and it's not mine alone,
is not the sysop's problem (although some DO complain) of having to
examine the whole mess, but the huge overall volume of data being sent.
My remarks dealt ONLY with such volumes of data and NOT the fact that
data files are being sent. In one bull I mentioned that I have sent and
received data files using YAPP, so obviously I have no problem with
REASONABLE file sizes.
Now I'm going to cut out of this temporal loop and get back to a linear
time line. Let's get the facts straight before we pick things apart and
quote or make references out of context, showing only what serves our
purpose and tell the WHOLE story, OK?
**********************************
WAN: The sound of a baby computer.
**********************************
73 de Warren, KB2VXA
e-mail: kb2vxa@juno.com
Message timed: 22:57 on 26 Aug 02 UTC
Read previous mail | Read next mail
| |
