Bundling vs sending serialized dependency graph

John Barton johnjbarton at google.com
Wed Aug 20 16:06:44 PDT 2014


On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson <ian at hixie.ch> wrote:

>
> ....
> > That's why in my opinion 'bundles' or 'packages' make sense: they
> > combine the related dependencies and allow them to be loaded in one
> > trip.
> >...
>
> This just doens't work.
>
> Suppose the dependency graph looks like this:
>
>      Feature A --> Dependency A1 \__\ Dependency    \
>      Feature B --> Dependency B1 /  /    AB          >--> Dependency D
>      Feature C --> Dependency C1 ---> Dependency C2 /
>
> All of A, B, and C are to be fetched on-demand-only, to avoid using up
> too much bandwidth. All the files here are non-trivial in size.
>
> How do you package this?
>
> If you make a package for A, a package for B, and a package for C, then
> you'll have redundant content in the packages, and when the client asks
> for B after already having asked for A, the amount of content sent back
> will be greater than necessary and therefore it'll be slower than
> necessary. If you create multiple packages such that you group as much as
> possible into each package as possible without overlap, then you still end
> up with multiple resources to download when you need any of A, B, or C.
> Basically, it boils down to:
>
>      Package A \__\ Package    \
>      Package B /  /    AB       >--> Package D
>      Package C ------------->  /
>
> ...and then you're back to the problem I asked about. If you don't have
> server-side support, then to avoid round-trips the client needs to know
> about the dependencies before it makes the first request. It can't wait
> til it receives the packages to discover the dependencies because if you
> do that then you're serialising your RTTs instead of pipelining them.
>
>
I assume you are imagining a densely connected graph with random access to
any of the roots. I expect that real life pages have well partitioned
graphs (widgets) that share some dense parts (utilities) and simple access
patterns -- main page, utilities, a set of widgets.

But sure, it would be great to have a complete solution if it's not a lot
more complex.

I guess you're proposing the send the dependency graph to the browser, then
when a new root is needed, the stored graph is compared with the
currently-loaded modules. The additional modules needed are then requested
as a group. Up to this point we can just use build tools and browsers. How
will we tell the server "send me this list of files all in one response?"

jjb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140820/1a96d24d/attachment.html>


More information about the es-discuss mailing list