Closed Bug 751758 Opened 12 years ago Closed 11 years ago

Try to estimate the size of appcache updates

Categories

(Core :: Networking: Cache, defect)

Product:
Core
Component:
Networking: Cache
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Project Flags:
blocking-basecamp -

People

(Reporter: cjones, Unassigned)

Details

Along with bug 751754, the use case here is to show users UI something like

  "An Irate Turtles update is available.  It's 10MB.  Would you like to download it?"
  [ Download ] [ Not now ]

This isn't possible in general, but for the cases we care about (well-maintained app stores), the servers should report the resource sizes for all URLs in the appcache.  If a server doesn't do this, we can report a sentinel "unknown" value.
Personally I tend to let this up to the marketplace.  Exposing the size per manifest URL via a web API is the best solution IMO.

HEADs preflight can be slow and if there is a lot of files it can also eat payed bytes when on 3G.
A fair number of resources won't implement HEAD correctly. That's always been the way. That doesn't strike me as critical here, but it is worth mentioning.
The user shouldn't need to go to a store to get an updated version of an app. Apps should update silently in the background just like we've started doing with firefox with the "silent update" project.
(In reply to Honza Bambas (:mayhemer) from comment #2)
> Personally I tend to let this up to the marketplace.  Exposing the size per
> manifest URL via a web API is the best solution IMO.
> 

The marketplace has nothing to do with the update mechanism.

> HEADs preflight can be slow and if there is a lot of files it can also eat
> payed bytes when on 3G.

Those are orthogonal problems.
(In reply to Patrick McManus [:mcmanus] from comment #3)
> A fair number of resources won't implement HEAD correctly. That's always
> been the way. That doesn't strike me as critical here, but it is worth
> mentioning.

Yep, see comment 0.  There will be a small number of stores initially so this isn't a big deal.  Those stores can lead the way.
Definitely worth adding that for the specific case of an installed app with a manifest, if the manifest is trusted, we can stick the size in there and save some effort.  That doesn't work for arbitrary appcache updates though, obviously.
Doesn't sound like we need to block shipping V1 of B2G for this, so Basecamp-. If you think we'd hold the release for this, re-nom.
blocking-basecamp: --- → -
No longer blocks: b2g-app-updates
Not much interest in doing this, so will close out for now.  Bug 744713 is lower-hanging fruit.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.