Re: Variant IDs

    >So suppose we wanted to provide our corporate home page in each
    >of (say) 30 different natural languages, since we do business in
    >at least that many.  Can you give us an example of the most compact
    >possible encoding of that variant set in your proposed URI header?
    
    Here it comes:
	[lengthy URI: header deleted]
    
    >One issue is "how many bytes does this encoding require"?
    
    925 bytes.
    
[Note: I asked about 30 different languages, and you gave me only
20, so I assume that the actual byte-count is around 50% higher!]

    Show me a homepage title image that is smaller.  I don't
    really see a problem with 1K URI headers.  If you do see a problem:
    don't you have the same problem with 1K Variant-Set request headers?

Not necessarily.  For one thing, the cache does not need to transmit
a variant-id for each possible variant, only for the ones that are
currently in its cache (i.e., for the ones that should not be
retransmitted).  Also, the syntax could probably be a lot more
compact.  Even if the cache held 20 variants, the result would
look something like:

    Variant-set: id=l1;l1abcdef, id=l2;l2abcdef, id=l3;l3abcdef,
     id=l4;l4abcdef, id=l5;l5abcdef, id=l6;l6abcdef, id=l7;l7abcdef,
     id=l8;l8abcdef, id=l9;l9abcdef, id=l10;l10abcde, id=l11;l11abcde,
     id=l12;l12abcde, id=l13;l13abcde, id=l14;l14abcde, id=l15;l15abcde,
     id=l16;l16abcde, id=l17;l17abcde, id=l18;l18abcde, id=l19;l19abcde,
     id=l20;l20abcde

which is approximately 350 bytes (I'm not sure if the white space
after the ","s is necessary).  This assumes a 32-bit opaque validator
encoded in hex; one might use a larger validator or a more efficient
encoding, so "your mileage may vary".  But note that if the cache
currently holds only (for example) 2 variants, then the Variant-set:
header would look like

    Variant-set: id=l1;l1abcdef, id=l2;l2abcdef

which is a lot less than 925 bytes!

    You _could_ send short but varying URI headers like
    
    URI: {variant "home.l1.html" 1 {language "l1"}},
	    {variant "home.l8.html" 1 {language "l8"}},
	    {variant "home.l14.html" 1 {language "l14"}},
	    {vary Accept-Language}
	
    under my proposal, but I do not really see the point of doing so: it
    only limits the ability of the user to request versions in other
    languages.

The main point is that people at the meeting on Friday (and previously)
have objected to design features that require transmitting huge numbers
of header bytes, since we expect a lot of low-bandwidth links (including
international or wireless) for the foreseeable future.

Several people also expressed concern about encoding variants in URIs,
for reasons that I cannot remember.  Perhaps they would like to state
these themselves?
    
    Another part of the question is: what is the best possible
    optimization if we do not have variant-set?  You can optimize the case
    by generating cachable(*) redirection (302) responses that redirect to
    cachable resources.  This is simple and gives optimal traffic savings,
    though at the expense of using two RTTs in the case that the cache is
    empty.
    
    (*) Note that 302 responses are never cachable under the current 1.1
    draft, but this can (will?) change.
    
For those of you (like myself) who have not quite memorized the
spec, 302 == Moved Temporarily.

-Jeff

Received on Thursday, 8 February 1996 00:38:25 UTC