Is "responses" the right goal?

[martinthomson]

First!

The original design here was framed as a response to some HTTP request. But I realize that the design and thinking has moved on somewhat since then. Treating this as a bundle of resources with metadata is both easier to reason about and less likely to trip into awkward problems (such as how this might interact with the HTTP protocol).

[jyasskin]

To digress about the history:

1. The original design in draft-yasskin-dispatch-web-packaging was around capturing a set of request/response pairs, on the theory that requests were the way to capture content negotiation. That turned out to be wrong: HTTP/2 PUSH never documented a design for how the PUSH_PROMISE's requests would match against the UA's requests.
2. So I shifted to a second design in draft-yasskin-wpack-bundled-exchanges-01 of bundling (URL, content-negotiation, response) triples, with the content negotiation represented using the Variants response header. But responses can already hold their URL in the Content-Location response header, and Variants is already a response header, which led me to rethink what it was we're actually storing.
3. So in draft-yasskin-wpack-bundled-exchanges-04, I defined the things in a bundle as "HTTP representations, themselves represented by HTTP response messages". 3 of the response headers get split out into discontiguous locations in the format (Content-Location becomes the key of the index map, Variants heads each value in the index map, and Variant-Key is implied by the order of the offset pairs in the value), but they're still logically response headers.

Why "representations" and not "resources"? HTTP defines resources as a very abstract concept. They're the abstract idea named by a URI (e.g. "the current weather in Laguna Beach"), rather than any particular serialization into bytes. Since bundles hold byte sequences, they can't really hold resources, but they can hold representations.

Given all that ... what kind of change are you looking for here?

[martinthomson]

That matches my recollection of the history also.

It's just the naming.

Saying "resources" is OK provided that there is no risk of being confused by the HTTP concept. A resource as exposed by HTTP is a rich and abstract thing that can do things, including produce representations. Here, the resource is far less capable, but it is still potentially also a resource. To that end, the distinction between a resource and its representation -- what motivates us to use the term "representation" at all -- is not important.

If we are no longer dependent on this being a representation of an HTTP resource, calling these representations implies the existence of some abstract resource that cannot be interacted with. The resource/representation split only invokes Plato's cave in what is a truly futile fashion.

That is to say, without any pretension, that this is a bag of bags of bits, with the metadata that allows computers to make sense of those bits.

[littledan]

@martinthomson 's reasoning makes sense to me. Maybe we should go back to calling this a "resource bundle" then?