[packaging-on-the-web] Link headers as an alternative? (#26)

Late to the party here, but I just read the spec and can't figure out what the advantages of this are over simply making links between things.  

HTTP/2 makes the number of individual requests irrelevant to perf or reliability, so I don't get the 'populating caches' use case (2.1).

In the web page use case (2.2), I can't see any benefit to linking to a package when you have a preload scanner that's going to harvest all the subresource links from the page anyway, you have preload hint headers to deal with anything the preload scanner doesn't spot, and serviceworker to cache atomic packages of resources if you want offline access.  Adding an additional permissions model for 'installing' a package seems redundant given other work (see Quota Management and Storage Durability)

Distributing libraries (2.3) is currently done using package managers that install multi-file packages from git repos, which seems to work OK, and the subsequent concatenation dramas are eliminated by HTTP/2.

In downloading data (2.4) with associated metadata, I guess it kind of makes sense that if you download a CSV you'd want the documentation too, but the current proposal would require anything that currently recognises the CSV format to now also recognise the new package format in order to make the new format as useful as the unpackaged original.  Your starting point is breaking all CSV readers, and then gradually fixing them by supporting the new format.  Wouldn't a better mechanism be to include links in the HTTP response headers, eg:

```
Link: rel=describedby; href=https://example.com/docs/about-my-csv.html
Link: rel=next; href=https://example.com/data/month-2.csv
```

etc.

I suspect I'm missing something quite blindingly obvious...

---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/packaging-on-the-web/issues/26