http2-push-manifest icon indicating copy to clipboard operation
http2-push-manifest copied to clipboard

A cleaner way to distinguish single-file and multi-file manifests

Open slightlyoff opened this issue 8 years ago • 2 comments

I'd like a flag in the format which declares easily (at the top-level object) which version of the format a file is using. Today, to make a determination, I've got hacky code which looks for the first entry in an object and probes it for type and weight properties. This sort of sucks.

Some options to consider:

  • A "file" object at the top-level which describes the contents?
  • JSON Schema definitions for the whole shebang
  • A single property to declare "single file" vs. "multi-file" and documentation which declares which one is the default
  • Have the http2-push-manifest tool ALWAYS generate multi-file manifests with a single "default" (or other sigil, perhaps *) property so that tools don't have to decide which to support

/cc @ebidel

slightlyoff avatar Feb 26 '17 18:02 slightlyoff

I don't have good insight into which format people are using more, the single vs. the multi-file format. I use the single format on some projects, where I read the manifest per handler. That's really simple. But I think other setups (e.g. static serving hosts) would be more inclined to use the multi-format. I'm up for making changes.

Either of your last two look good. Ditching the difference and always generating the same format (multi-file) might be the way to go.

Might leave this open for a bit to let others chime in before we deprecate anything.

ebidel avatar Feb 26 '17 19:02 ebidel

The multi-file format is what you'd want to use to avoid over-push but maintain a single manifest file (e.g. from the Polymer build scripts); else you need to generate one manifest per entry-file (assuming they differ at all). It gets complicated quickly as some SPAs will want MOST pages to load one set of files (simple apps) but will eventually need to send a different bundle for a different "page type" (which might also cover a large number of routes). I'm trying to avoid changing this format to accommodate those cases but the current situation pushes complexity into tools (who will inevitably diverge on the meaning of what the word "is" is).

slightlyoff avatar Feb 27 '17 00:02 slightlyoff