I don't think anybody's in actually disagreeing with that *should* be
released into the network -- what we're discussing borders more on the
philosophical than the practical, really.
 
Programmers like me just plain old don't like limits, particularly not
arbitrary ones (which may not have been arbitrary historically). Instead,
we prefer to code for ridiculous usage patterns, and let the users specify
what the limits really ought to be -- unless, of course, a specification
somewhere (not a de-facto standard) says otherwise. I guess that's why
programmers like me tend to become UNIX Systems Programmers. 
 
Along with this same philosophy (for me, anyhow -- philosophy is a pretty
personal thing) comes the "accept lenient; write strict" mode of
operation. That is, accept malformed input where it is possible to
determine the correct output, but NEVER produce incorrect output (even if
"every system out there will accept it").
 
These two things tie into the desire to let the users limit their input and
output max message sizes, but to set the default limits extremely high for
input, and "de-facto standard" for output.
 
Of course, then the practical side has to kick in -- accepting literally
infitely large input is not possible by definition. But a really good
substitute for infinitely large exists in our world -- the maximum address
space of the CPU minus the size of the code itself; in practice, the
biggest file you can memory map on a modern UNIX (mmap files essentially
become part of the VM subsystem when in use).
 
So where does that leave the theoretical maximum input size for Squish (if
I ever get around to tuning it)? -- around 2 GB (in practice) on a 32-bit
system. Some trickery can be employed to double that, but I doubt the
effort-gain ratio is worth it, even for adherence of my (perhaps strange)
philosophy. Of course, you can go beyond the 4GB limit as well (the same
swap technique as Scott uses for big messages under DOS), but that has
other drawbacks (namely, significantly increasing the effort required to
produce correct code -- not to mention testing it).
 
And for what it's worth, I already have some *excellent* ideas for tuning
Squish/msgapi from a code-review point of view. But I won't devote one
moment of time to that until long after the base product is stable. Unless,
of course, I get horribly bored someday and feel like doing it. You know
how that goes. :)
 
Wes

--- Maximus/2 3.01