Hello Wes!

12 Jun 03 22:44, Wes Garland wrote to Mike Tripp:

 WG> I don't think anybody's in actually disagreeing with that *should* be
 WG> released into the network -- what we're discussing borders more on the
 WG> philosophical than the practical, really.

OK...far be it from me to ask anyone to dilute their philosophical limits.
:) And shame on me for assuming that the objective for increasing the max
message size was to generate messages larger than the current limit.  I
would certainly plead "guilty as charged" to being heavily
weighted to the practical over the philosophical, especially when testing
requirements documents (and yes, they do exist outside the programmer's
context).

 WG> These two things tie into the desire to let the users limit their
 WG> input and output max message sizes, but to set the default limits
 WG> extremely high for input, and "de-facto standard" for output.

Not quite sure I understand the logical distinction here.  In this
application, one man's output =is= another man's input.  Also, a
(philosophically) infinite number of nodes could suffer hampered/halted
mail flow if one man's output fails to conform to another's assumptions
about input.

 WG> Of course, then the practical side has to kick in -- accepting
 WG> literally infitely large input is not possible by definition.

Yep...and my philosophy would be to reject the requirements document as
being "infinitely unimplementable", and say "try again"
or "take what I can deliver instead". :)

 WG> But a really good substitute for infinitely large exists in our
 WG> world -- the maximum address space of the CPU minus the size of
 WG> the code itself; in practice, the biggest file you can memory map
 WG> on a modern UNIX (mmap files essentially become part of the VM
 WG> subsystem when in use).

A good substitute if you happen to be using "a modern Unix"...but
(practically) equally as undefined as "infinite"...since CPU,
code size, and available virtual memory are probably less consistent on
"a modern Unix" than anywhere else.

Not trying to detract from what you're doing, I'm all in favor of...but
since OS platform portability was the first sjd feature stricken off the
list as this code branch started, my ears perk up if it sounds like I also
might have issues with uplinks/downlinks running it...even if I don't end
up using it myself.

.\\ike

--- GoldED 2.50+