Taylor Blau <me@xxxxxxxxxxxx> writes: > I don't have a huge problem with "content_limit" as a name, but perhaps > "content_size_limit", "streaming_limit", or "streaming_threshold" (with > a vague preference towards the latter) might be more descriptive? I > dunno. Your statement does highlight the second point that should have been pointed out, but I failed to. The "limit" is about "maximum content size" (as opposed to content type or color or smell), but also it is important to avoid sounding like we are forbidding a blob to exist if it is larger than that limit. The limit is only about whether the contents are prefetched through the contentp pointer (and anything larger than the limit must be obtained via a separate API call to obtain the contents). We can flip the polarity to say "minimum content size to stream" (i.e., anything larger than this threshold will be streamed out instead of held in core at once), and it may certainly be a better way to explain what is going on than "maximum content size to be held in-core via contentp". Thanks.