Re: Packaging on the Web

On Wed, Feb 5, 2014 at 2:46 AM, Jeni Tennison <jeni@jenitennison.com> wrote:

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


If we can't overcome the per-parser issues, then I think the balance swings
to changing URL parsing in a way that seeks to minimize unintended
consequences.


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

Unclear. It's a foot-race, after all. A client will do request to get the
document, which usually streams in pretty quickly relative to the RTT's you
need to navigate for sub-resources. This is confounded by advice like this
which indicates to authors that they should be requesting some resources as
early as possible in their documents:


https://developers.google.com/speed/docs/best-practices/rtt#PutStylesBeforeScripts

This is especially important for resources that are going to be fetched
off-origin and for which warming up DNS can add considerable latency.

If we consider the MTU that causes the first couple of packets to be
several K of content, and an RTT for the pack file on the order of 100ms
(conservative, but not outlandish, particularly on mobile), I think we'd
lose the race for many resources in the <head> of a document. Not where we
want to be, and it gets worse the higher the latency on the network.


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

I'm going to try to come up with alternatives, but I think the globbing
pattern + a manifest-as-first-item strategy is the only thing that can save
this from the fire. Without some knowledge of which pre-flighted requests
to delay on package files, I fear pre-scanning is fatal.



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

Received on Thursday, 6 February 2014 02:17:46 UTC