From: Brad Templeton (brad@templetons.com)
Date: Tue Jul 03 2001 - 13:33:53 CDT
On Tue, Jul 03, 2001 at 11:49:55AM -0400, Bill Davidsen wrote:
> Brad Templeton <brad@templetons.com> wrote:
>
> Of course, how else would the articles be available. If a site doesn't
> want binaries they don't ask for them, if they ask for binaries but
> <1MB, they obviously have other issues.
>
> There are some technical reasons for this, one might be to avoid
> people endlessly trying to download larger articles, one might be their
> filesystem not handling larger articles well. Since there's no
> interoperability problem, we should we try to solve it?
Um, this is going in circles. I'm proposing that the standard require
that the software _technically_ handle articles of a least "X" (where X
to my mind would be in the 5MB range though some like 1MB) so as such,
the main reason a site would put on such a limit would be for policy
reasons, namely to conserve resources. And they would want it set at
their feed, probably not at their own site. (Ie. feeding software would
offer a flag to say, "Don't send articles larger than Y bytes.)
This would be for sites that want to get alt but just don't want megabyte
articles.
These sites would not say "we want the megabyte articles if they are
annoyingly split up into 20 parts" It doesn't want them at all.
I continue to say, if your software has bugs that make it unable to handle
a 1MB article well, don't redefine the article format, _fix the bugs_.
> And my main point which you have totally avoid addressing is: since
> all lower limits previously used by usenet have dropped out of common
> use, and there is no flood of people using smaller sizes than they must,
> why do you feel that we suddenly need it?
>
> I expect you to ignore the question again...
No, I haven't avoided it. You know how these threads get. Nobody knows
what "smaller than they must is" because the standard provides no guidance.
We all seem to feel that megabyte chunks are workable with today's software
but I don't see those in a multipart. In some groups like the ones for
mp3s sizes of 300-400K per piece are common, resulting in videos taking
multiple hundreds of parts.
I could contend a site wither wants the 40mb file as a unit or doesn't want
it at all. It doesn't want 250 parts, of which no doubt fairly often
one is missing.
Anyway, it probably is time to end this. I mainly wanted to defend the
philosophy (while we still have the chance and the switch to
message/partial from multi-article uuencodde has not yet begun) that
article disassembly and reassembly belongs in the transport tools, not the
article format.