Closed Bug 752705 Opened 12 years ago Closed 12 years ago

add "appcache update" mode to runtime and make installer use it to update appcache on install

Categories

(Firefox Graveyard :: Webapp Runtime, enhancement, P1)

Product:
Firefox Graveyard
Component:
Webapp Runtime
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
Firefox 15

People

(Reporter: myk, Unassigned)

References

Details

Over in meta-bug 744712, the appcache is being enhanced to support progress updates, so code can request that cached resources be updated and get updates on the progress of downloading and caching those resources.

The installer should download and cache resources for an app when it is initially installed, such that an app has all the resources it needs to run on the local machine at the time it is first run.

In talks with platform team folks (honza, sicking, bent), it seems like the best short-term solution, given the intricacies of trying to share an appcache between multiple processes using multiple profiles, is to add a command-line flag to the runtime that causes it to tell the appcache service to download and cache resources, get feedback on progress from the service, pass that back to the process that invoked it, and then quit.

So a Firefox process, after installing the stub executable, can invoke the runtime with the flag, get progress updates from the runtime as resources are downloaded and cached, and display the progress of the caching to the user in the form of an "installing app" progress bar.

It isn't yet clear how to get progress updates from the runtime process back to the Firefox process that invoked it. There are some IPC mechanisms in the codebase, but they may not be appropriate. We might be able to get away with something as unsophisticated as having the shell process write to stdout. Ben Turner (bent) has offered to help figure this out.  cc:ing him.
Myk - Could you explain the rationale for nominating this for kilimanjaro? Also, should we nominate this snappy?
nominate this for snappy*
(In reply to Jason Smith [:jsmith] from comment #1)
> Also, should we nominate this for Snappy?

CCing Lawrence Mandel who can probably answer that request.
Depends on: 744712
I don't understand how this should work. Where would webapprt get the link to the .appcache?
So the current idea is:
1) load webapp in FF using XHR and check manifest attribute in <html> element.
2) install webapp
3) create profile folder for the webapp (this may need some changes to the profile service)
4) pass the path to profile folder and url to .appcache to appcacheservice which can then
   load the appcache and store it in the target profile. AppcacheService notifies some UI
   thing about the progress. (this needs some changes to appcacheservice)


So, no IPC involved.
Depends on: 753990
(In reply to Olli Pettay [:smaug] from comment #5)
> 4) pass the path to profile folder and url to .appcache to appcacheservice
> which can then
>    load the appcache and store it in the target profile. AppcacheService
> notifies some UI
>    thing about the progress. (this needs some changes to appcacheservice)

Reported bug 753990 on this.
Priority: -- → P1
Target Milestone: --- → M1
No longer depends on: 753990
Priority: P1 → --
Target Milestone: M1 → ---
Priority: -- → P1
Target Milestone: --- → M1
Blocks: 749029
Moving this to a blocker per the dependency - this is the correct way to offline mode to work for apps.
Whiteboard: [blocking-webrtdesktop1+]
No longer blocks: 749029
Whiteboard: [blocking-webrtdesktop1+]
Btw, I'm looking at the install part of this bug only.
Component: Desktop Runtime → Webapp Runtime
Product: Web Apps → Firefox
Target Milestone: M1 → Firefox 15
Myk, is this a blocker?
Actually, I think we should WONTFIX this bug since we've decided to go with a somewhat different solution for app installation. See bug 753990. I'll file a new tracker bug for that strategy.
(In reply to Jonas Sicking (:sicking) from comment #11)
> Actually, I think we should WONTFIX this bug since we've decided to go with
> a somewhat different solution for app installation. See bug 753990. I'll
> file a new tracker bug for that strategy.

Sounds good. Myk - Do you agree or disagree?
I agree.  Bug 753990 was my preferred solution back when we originally speced this one, and I'm glad to hear that it looks possible after all.
Status: NEW → RESOLVED
blocking-kilimanjaro: ? → ---
Closed: 12 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.