Re: Packaging on the Web

Alex,

> > 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">

Thoughts?

Cheers,

Jeni

[1] https://github.com/w3ctag/packaging-on-the-web#specialising-urls
-- 
Jeni Tennison
http://www.jenitennison.com/

Received on Wednesday, 5 February 2014 10:46:39 UTC