Alex Russel: There are salvageable parts in AppCache, but we are more interested in kernelizing.

Alex Russel: Create seperable capabilites - 'camp' on URL space.

Alex Russel: Atomically cache a group of resources.

Alex Russel: Make it more declarative, allow developers to group resources.

Alex Russel: These are good things we would like to reserve.

Alex Russel: Disadvantage: it works on the level of HTML resources.

Alex Russel: Describe an AppCache in terms of primitives needed and then provide them as independend units.

Alex Russel: There is no 'life cycle' for a link - whatever is done is 'magic' in the browser as far as application and user is concerned. Not well defined.

NOTE: Number of attendees in this session: 46

Alex Russel: Should make large parts of AppCache optional and provide individual functions underneath it.

Alex Russel: Create independend app cache groups and version and handle them independently.

Alex Russel: App cache puts your app in a shell - fundamentally different from normal web where a link can take you anywhere. Currently AppCache allows you only to stay within your shell, good luck if you try to go out of that.

Alex Russel: @@: Does that work similar to the online cache handling?

<richt> FYI, some recent Fixing AppCache CG meeting notes may be useful for participants in this room: http://www.w3.org/community/fixing-appcache/wiki/Meeting_notes_14_August_2012

Alex Russel: Well, conceptionally yes.

s/Alan Russel: @@:/@@:/

<tobie> richt: or better yet: https://etherpad.mozilla.org/appcache and https://etherpad.mozilla.org/appcache-london

<richt> yep. thx tobie.

One of the way to do offline app is the widget stack or equivalent application stacks that browsers have.

Widget apps are inherently self-contained.

How do you take the widget-typr runtime and make it deal with more appcache based apps?

Why can't wie just put all the resources in a file, zip thhem and call them a widget.

Jonas Sicking: Firefox basically does that. Either you have a zip or you point to a manifest which in turn points to the resources.

Jonas Sicking: To the user these behave the same.

Jonas Sicking: Basically it's just caching stuff that's normally on the web. Individually linkable/accessible URLs.

Jonas Sicking: Side effect: Each application is more sandboxed than running it directly from the web, which can be confusing. A ZIP file is conceptually recognizeably more different.

Jonas Sicking: People have more understanding that you put stuff in a ZIP file and only stuff in that ZIP file will be available offline.

Jonas Sicking: App cache makes it hard to sign resources - way too conplicated and fragile.

Jonas Sicking: Signing really only works properly on ZIP files.

Is the problem going all over the web and collect signatures?

Jonas Sicking: Partly. But also you need to have the signatures somewhere and app caches don't have proper extensions to allow for that.

Jonas Sicking: Also, we wanted to have third-party signature. Meant that you had to send the resources to a third party, get signature back and put it in app cache.

Jonas Sicking: Gets very awkward quickly.

Ashok: Are there other ways of doing offline apps?

Alex Russel: Two issues - who do I refer to applications. What is the way to get to resources.

Alex Russel: Both are independent.

@@: Possible also to use file system. Example: Opera Unite used to have a file system API.

Charles McCathieNevile: Different from IndexDB or local storage - you can share with other applications and non-web stuff.

@@: Makes it less painfull for applications to share something, with the user controlling who gets the access/

<richt> I think this response from Mozilla may shed light on the File System access and its issues: https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/

Ashok: How do you sync your data?

<richt> ...that @chaals was talking about.

Ashok: Typically this is a very difficult project - moved from this to this and lost all my data.

Alex: In the short run we leave it to app authors to get it right. Not a very good solution.

Alex Russel: The good thing with widget-like approaches is that it doesn't give you the illusion that you just make a web page offline-able. When you sit down and type the manifest file, you know that you do something different from that.

Jonas Sicking: We wanted to make sure that we put enough additions to the spec to handle things, but we knew there would be no way to sync user data across storage. If we tried to do that, we would just ensure that we scrambled.destoryed user data.

s/scrambled destroyed/ scrambled or destroyed/

@@: Basic problem with sync is that it is easy to sync data, the problem is to sync which bits in a structure with which?

@@: When should the app data overwrite/update the local storage.

@@: Has been covered and solved lots of times, but no tools available in web architecture.

Ashok: Finally conflicts need to be pushed back to the apps and solved there, which is hard to do.

Alex: You don't sync the state of the database, you sync on the logs.
... The tricky thing is to find out (after time sync between instances) which is the last high level operation that caused a change.
... The situation is even worse than Ashok describes. Handling of ViewStates. There are frameworks that create a data model and use viewstate essentially as a rendered, so sync needs to be within model, not the DOM.
... An application needs to communicate model changes not just the markup change effects resulting from that.
... Unless you are having a model or architecture there is no clear consensuns what we are really taking offline - a page? data? functionality?

@@: Maybe we could define an offline vs. online state or even a mixed state where an app knows which resources are available in an individual state.

@@: An app in a car might have online/offline states with the same application but different resources available.

Alex: Tricky - what if you are in a tunnel. In the two minutes of TCP/IP time out - what is your state?

@@: Might just need a small bit of code to be added.

Alex: I'll be waiting for your small bit of code.

@@: Might not be that small.

Alex: If you are building an app, you should be building on local data primarily with other resources being an add-on. Basically the (working) definition of an app vs. a web page.

Ashok: We're rnning short on time.
... Might be some proposals for improving app cache.
... But maybe not.

Jaques: I would like to see examples for the tools helping with state sync and similar tasks.

Jacques: Could the export provide a list of examples?

@@: I'll write something and someone will be so annoyed at this that they fix it.

Ashok: Thanks!

@@: I'll put it on the TPAC wiki (whatever the page is/offline).

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

FAILED: s/Alan Russel: @@:/@@:/
Succeeded: s/@@/Charles McCathieNevile/
Succeeded: s/make sure/ensure/
FAILED: s/scrambled destroyed/ scrambled or destroyed/
No ScribeNick specified.  Guessing ScribeNick: CF
Inferring Scribes: CF

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: Alex Arnaud Ashok Cris DKA Jacques Jaques Javi Javi__CTIC_ Jirka Juhani K2 NOTE Wonsuk adrianba_ chaals efullea jsoh kotakagi leif nwidell paul-hw richt schuki tidoust tobie tokamoto tomoyuki
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 31 Oct 2012
Guessing minutes URL: http://www.w3.org/2012/10/31-offline-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report