Re: Variants and Client Hints

[Yoav Weiss <[e-mail]>]

On Wed, Jun 13, 2018 at 7:27 AM Mark Nottingham <[e-mail]> wrote:

>
>
> > On 8 Jun 2018, at 11:33 am, Yoav Weiss <[e-mail]> wrote:
> >
> > On Fri, Jun 8, 2018 at 11:12 AM Mark Nottingham <[e-mail]> wrote:
> >> Hi Yoav,
> >>
> >> On 8 Jun 2018, at 10:55 am, Yoav Weiss <[e-mail]> wrote:
> >>
> >> For example, let's say that we say the rule here is "next smallest." A
> server that prefers quality can take that into account and up the quality
> of their images, relative to the sizes they make available. If they want to
> go back to the origin, they won't use Variants; they'll fall back to Vary.
> >
> > High quality but upscaled images will end up upsetting everyone (as
> they'd end up blurry and bloated).
> >
> > The inverse (i.e. a "next largest" algorithm) might be a better choice,
> but I suspect it won't satisfy some people's use cases.
>
> Hm. A little more?
>
> >> I don't think adding more complexity to the protocol is justified here;
> people can meet their use cases (at least as far as you outline above) with
> just one algorithm.
> >
> > I'm not sure I see how. Could you outline an example?
>
> See below.
>
> >> My thinking to date has been that extra information of this sort could
> be encoded in the available-value if necessary -- but it'd be nice to have
> a worked example. Note that the syntax of available-value opened up in the
> latest draft; if more characters would help, we can figure that out.
> >
> > Are you suggesting that origins will communicate in the available-value
> e.g. the ranges of viewports that an image can satisfy? That may work if we
> ignore the potential cross-conneg-mechanism interactions.
>
> That's one possibility, At the end of the day, available-value is just a
> string under control of the spec, and the algorithm can do pretty much
> anything as long as it produces appropriate outputs (although if it relies
> on inputs not listed, it's going to raise the bar for implementation). The
> tricky bit is likely to be making it succinct.
>
>
> >> That said, the syntax of Variant-Key now allows a response to match
> multiple keys, which at least helps in the duplication issue; see the last
> part of:
> >>
> https://httpwg.org/http-extensions/draft-ietf-httpbis-variants.html#variant-key
> >
> > I agree that's better, but still, the response for `DPR: 2, Viewport:
> 300`, `DPR:1, Viewport: 600` and `DPR: 2, Viewport: 600, Save-Data: on`
> could be one and the same. Avoiding that cache duplication can be an
> important factor.
>
> Right, but that response would have on it something like:
>
> Variants: DPR;1;2, Viewport;600;1200, Save-Data;on;off
> Variant-Key: 1;2, 600, on;off
>
> If that's not expressive enough, maybe we should be talking about a
> Variant-Key syntax that lets you specify alternative sets of values, e.g.,
>
> Variants: DPR;1;2, Viewport;300;600, Save-Data;on;off
> Variant-Key: 2;300;off, 1;600;off, 2;600;on
>

I like the expressiveness that second syntax enables.

Just to clarify: when processing the keys, we're not relying on ordering,
but on the values declared as potential variants, right?

If so, I can see cases where the variants values may have collisions (e.g.
if `Save-Data` were defined as "0" and "1" values, it would collide with
DPR). At the same time, I'm not sure this will be a problem in practice,
and we can probably avoid it becoming a problem by being careful about
future client hint values and their interactions with existing ones.


>
> --
> Mark Nottingham   https://www.mnot.net/
>
>