Re: Variants and Client Hints

> On Jul 10, 2018, at 9:57 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 
> 
>> On 11 Jul 2018, at 2:31 am, Leif Hedstrom <leif@ogre.com> wrote:
>> 
>>> 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
>> 
>> This seems rather convoluted, almost aching to the complexity of the old “Key” draft. And now instead of having one secondary cache key, I might have 3 (or <n>) that I must look up? I agree that deduping in the cache is admirable, but perhaps that is an implementation detail for the caches or services?
> 
> I'm not sure that's the right characterisation; it lets you register this response for three different keys; i.e., you don't have to look for three different things on each request, you just have to do one lookup and find the appropriate key (which might be any of these three).


Assuming the request only satisfies one of those secondary cache keys, right? Is it possible / allowed that a request could match multiple of these Variant-Keys?

And what if a response comes back with 10,000 secondary keys. We let it do that? What if they overlap with other objects primary cache key? Is that an issue?

> 
> Also, note that the form at the top (in the first example) is already in the spec; are you pushing back on that? It also has the capability to assign multiple keys to a single response, just in a more limited way.

No, not pushing back on anything. Just concerned that we’re making things more complex, and potentially expensive on the server. :-).

> 
> Personally, I like the second form; it seems like a good balance between complexity and the capabilities that people have been repeatedly asking for here.
> 

Fair enough. I see that there’s a session in Montreal covering this topic, maybe that’s a good time for clarifications?

Cheers,

— Leif

Received on Wednesday, 11 July 2018 15:57:25 UTC