- From: Martin Thomson <mt@lowentropy.net>
- Date: Fri, 20 Mar 2020 08:34:08 +1100
- To: ietf-http-wg@w3.org
Do we want approximation or a cap on size? An upper bound is good for some of the use cases we see. An estimate for the other cases. At the extreme, you might say X +/- Y with Z confidence. With fields for each. That sounds like overengineering, but it doesn't have to be complicated in common usage. You could say that Y and Z are implied or have defaults to simplify the common case. From that a recipient can build to whatever assumption they like. Find a value of f(Z) for X + Y*f(Z) that suits you. Just want to show a progress meter, then f(Z) = 0 is probably fine. Want to allocate space with a low risk of overflow, then you might want something like f(Z) = 2/Z. On Fri, Mar 20, 2020, at 03:28, Willy Tarreau wrote: > On Thu, Mar 19, 2020 at 04:25:03PM +0000, Poul-Henning Kamp wrote: > > -------- > > In message <20200319161130.GA19209@1wt.eu>, Willy Tarreau writes: > > >On Thu, Mar 19, 2020 at 03:53:32PM +0000, Poul-Henning Kamp wrote: > > > > >> We could make it explictly fuzzy, by definting it as kilobytes rounded down ? > > > > > >I think it's an excellent idea, which even goes in the direction of > > >reducing the on-wire bytes. And given todays connections speeds, if we > > >use it only for progress bars it could even represent megabytes rounded > > >to the nearest. Less than 0.5 will usually not take more than a few > > >seconds and not deserve showing an accurate progress bar. > > > > I thought about that, but I know of applications where traffic is sorted > > in "small", "medium" and "huge", where "small" is significantly less than > > a megabyte, so I think the units should in the kilobytes rather than > > megabytes range. Just to throw a number out there: Smaller than 32k. > > I'm fine with this anyway. > > Willy > >
Received on Thursday, 19 March 2020 21:34:42 UTC