Closed Bug 790669 Opened 12 years ago Closed 12 years ago

convert packaged apps installs to use a mini-manifest

Categories

(Marketplace Graveyard :: Consumer Pages, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED
2012-09-20

People

(Reporter: clouserw, Assigned: robhudson)

References

Details

Right now when we call installPackage we pass in the location to a zip file (the package we're installing).  In order to scale to new features in the future we've decided to pass in a small manifest instead, which we will be able to expand in the future as other interesting uses appear.  Read bug 789527 for details about the mini manifest.

This bug is about:

1) Create a URL to generate mini-manifests per version of packaged apps.  These should be available off the CDN's domain, so send it with far future expires headers and a cache busting token in the URL (maybe a short-hash of last updated date from the db?)

2) Adjust the front end to use the new URL instead of the package URL in installPackage().  We do not need to maintain the old way of installing packages.

Fabrice can help with questions about implementation (he's doing the client side).  While this bug and bug 789527 are not both in the same state (both open or both closed) installs will be broken.  I expect the client bug to be closed within the next week.
I know basta had some comments about this.
Questions:

1. Which URL does FirefoxOS check for these? Is it a single URL with the addon passed in a query string (like we do for add-ons)? Or is it a unique URL per app, similar to the app detail page where the user likely installed the app?

2. What extra info does FirefoxOS send our way, either via query string parameters or headers that we need to know about?

3. What does FirefoxOS expect in return? Anything besides what's referenced in bug 789527? For example, headers we should set like Content-type, Etag, etc?

4. This bug mentions a cache busting token. I'm not clear on how this will get updated when new versions are pushed out via the marketplace, and how FirefoxOS will pick up the new tokens to "bust" the cache.
Hi Rob,

Here's my understanding:

(In reply to Rob Hudson [:robhudson] from comment #2)
> 1. Which URL does FirefoxOS check for these? Is it a single URL with the
> addon passed in a query string (like we do for add-ons)? Or is it a unique
> URL per app, similar to the app detail page where the user likely installed
> the app?

We will check the manifest URL. This is important to let any website to host such packaged apps.
 
> 2. What extra info does FirefoxOS send our way, either via query string
> parameters or headers that we need to know about?

We expect the If-none-match header to be honored.

> 3. What does FirefoxOS expect in return? Anything besides what's referenced
> in bug 789527? For example, headers we should set like Content-type, Etag,
> etc?

Etag please! and maybe content-type, but I don't know which type we want.
 
> 4. This bug mentions a cache busting token. I'm not clear on how this will
> get updated when new versions are pushed out via the marketplace, and how
> FirefoxOS will pick up the new tokens to "bust" the cache.

I have no idea what his token is either, sorry.
Thanks Fabrice...

> > 3. What does FirefoxOS expect in return? Anything besides what's referenced
> > in bug 789527? For example, headers we should set like Content-type, Etag,
> > etc?
> 
> Etag please! and maybe content-type, but I don't know which type we want.

For now I'll use Content-type: application/x-web-app-manifest+json, but we can change this if we have to.
Target Milestone: 2012-09-13 → 2012-09-20
(In reply to Wil Clouser [:clouserw] from comment #0)
> 1) Create a URL to generate mini-manifests per version of packaged apps. 
> These should be available off the CDN's domain, so send it with far future
> expires headers and a cache busting token in the URL (maybe a short-hash of
> last updated date from the db?)

Part 1 is done in this commit:
https://github.com/mozilla/zamboni/commit/8a0cd4d 

With the following differences:

* The mini-manifest isn't per version, it's always the most recent approved version. This means we can't install old versions of packaged apps. If we did a per version URL, I'm not sure how updates would work?

* No caching headers or tokens are used. I filed bug 791843 to follow up with this.

Part 2 is next...

> 2) Adjust the front end to use the new URL instead of the package URL in
> installPackage().  We do not need to maintain the old way of installing
> packages.
Bug 792146 is for updating the front-end to use this manifest URL.

Closing as fixed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.