(original) (raw)

Oh-oh. What exactly are you uncomfortable with? (Roy, please answer this too)

• representation resources being first class objects with their own URIs?

Okay -- representation resources are resources too.

• a response from the representation resource with URI TheProject.en.html being included in a response to a request on the resource with URI TheProject?

Okay -- necessary for older clients and saves second request in common case.

• the fact that reactive negotiation, which is done with a request on the representation resource URI TheProject.en.html, necessitates, for efficiency reasons, the sharing of cache slots?

Ummm, depends on what you mean by cache slots. The cache key is the Method+Request-URI (regardless of what was returned in URI) for security reasons. The cache slot pointed to by the key should contain the request modifiers/vary information and metainfo necessary for cache updates, and point to each of the cached responses. Right?

• having two blocks of headers in the preemptive response?

Makes me a bit queezy. Keep in mind that a 1xx response can't be sent to 1.0 clients, so it is difficult to transition this as an implementation.

• the information in the URI header being cachable separately?

I'd prefer just making the URI header information correspond to the Method+Request-URI cache key and not allow it to change per representation returned. That way, it can be in the single response.

• something else?

I wonder if it would make you less uncomfortable if I go back to my old scheme in which the Representations: (used to be URI:) header has its own fields to control caching. As I explained before, I feel that it is necessary to allow service authors to control caching of the Representations: headers independent of the caching of the representation resource responses.

Any chance we can make that "Reps:"? Hmmm, how about "More:"? Or "Variants" or "Alternates". It is really hard to say 5 syllable words while giving a presentation.

.....Roy