790872 - Implement update for hosted apps

Status: RESOLVED DUPLICATE of bug 790870

(Core Graveyard :: DOM: Apps, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Implement the API described in bug 790558 comment 0.

We'll be very limited in what we can do here due to limitations in the appcache. We need to figure out how we can make it work best.

Comment 1

[Jason Smith [:jsmith]]

(In reply to Jonas Sicking (:sicking) from comment #0)
> Implement the API described in bug 790558 comment 0.
> 
> We'll be very limited in what we can do here due to limitations in the
> appcache. We need to figure out how we can make it work best.

I might sound like a crazy person with this comment, but is support for third party app updates for hosted non-packaged apps a basecamp blocker? Originally I was thinking all third party app updates was as it was explicitly called out as a v1 requirement, but...

In being involved with the app review process in the past, I didn't notice a lot of changes to the app manifest after it was put up, unless we complained to the site for some critical reason for them to change their manifest. Andrew (cc-ed here) probably can provide more context here, but I just never really received the impression of app manifests were changing that much. What's the risk here for deciding to cut this? Not trying to be a pain in priority analysis, just trying to keep on the radar that we're on a tight schedule. 

Note - I 100% believe though that packaged app updates is a blocker, as that relates to a need to keep content up to date, which warrants it's high priority need.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Mostly what we want to update here is the appcache'd resources used by hosted app.

I agree that updating the manifest itself is probably not critical for v1.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Jonas Sicking (:sicking) from comment #2)
> Mostly what we want to update here is the appcache'd resources used by
> hosted app.
> 
> I agree that updating the manifest itself is probably not critical for v1.

That makes sense.

Should we split this bug up for implementing the appcache update for hosted apps in one bug and have another bug implementing the app manifest update for hosted apps? Or is this bug already tracking one of these two things and something else is tracking the other?

Comment 4

[[:fabrice] Fabrice Desré]

Let's not split that further. We need to get the manifest anyway to check if the location of the appcache manifest has changed. We'll implement everything in this bug.

Comment 5

[Andrew Williamson [:eviljeff]]

(In reply to Jason Smith [:jsmith] from comment #1)
> In being involved with the app review process in the past, I didn't notice a
> lot of changes to the app manifest after it was put up, unless we complained
> to the site for some critical reason for them to change their manifest.
> Andrew (cc-ed here) probably can provide more context here, but I just never
> really received the impression of app manifests were changing that much.

I never got that impression either - though the App only gets flagged for re-review for significant changes so something like new icons we'd not be notified about.  I think most developers assume manifest updates do happen automatically though, given the way we've positioned webapps as always up to date because its effectively a website.  That said, I'd agree with Jason its not a basecamp blocker as manifest updates can happen in-app with mozapps.install()

I'm assuming the updates we're talking about are updating the existing manifest with a new one located at the same url - is there a plan to support updates from Marketplace of manifest url changes?  It does happen on occasion after approval, normally when the domain name changes.

Comment 6

[Mounir Lamouri (:mounir)]

Fabrice told me he was or will work on this. Updating the assignee field to make this clearer.