W3C home > Mailing lists > Public > www-tag@w3.org > February 2014

Re: Packaging on the Web

From: Jeni Tennison <jeni@jenitennison.com>
Date: Wed, 5 Feb 2014 10:46:11 +0000
To: Alex Russell <slightlyoff@google.com>
Cc: "www-tag@w3.org List" <www-tag@w3.org>
Message-ID: <etPan.52f21673.7c83e458.4c96@jenit.local>

> > Yes, it’s not as conceptually elegant a solution as I would like either.
> > The more elegant approaches that I looked at had larger drawbacks, as I’ve
> > documented. Can you think of another way of approaching this that I’ve
> > missed?
> Yehdua's proposal (changing URL parsing) avoids the issue by  
> conflating addressing with package location.

Yes, but as I’ve written [1], it has larger architectural drawbacks in baking new syntax into URLs. Do you disagree with that analysis?

> > I’m not convinced that having to make a request before making another
> > request for a package is a fundamental problem. I know that the point of
> > the packages is to minimise the number of requests that are made, but the
> > BBC home page, for example, involves 110 requests; doing 2 rather than 110
> > seems like a win.
> Again, please see the discussion of pre-parse scanners. It's unclear
> (without some other signal, say a globbing pattern that's part of the
> to indicate what resources are in the package and which aren't) that
> we will actually avoid the extra fetches in practice under the proposal.

Sorry, I’d missed that because my email client had "helpfully" hidden it as quoted content. Sigh.

Does having a simple textual manifest file that just lists the content of the package as the first item in the package help at all?

Or, as you suggest, a globbing pattern, which could be a parameter on the content type both on the link and on the response to the request for the package. For example:

  <link href="assets.pack" rel="package" type="multipart/package;glob=/assets/*,/favicon.png">




[1] https://github.com/w3ctag/packaging-on-the-web#specialising-urls
Jeni Tennison
Received on Wednesday, 5 February 2014 10:46:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:01 UTC