Offline Web Apps Workshop -- 05 Nov 2011

<inserted> ScribeNick: noone

<dom> Papers submitted to the workshop

<mwbrooks> Do we have a Twitter hashtag?

<dom> mwbrooks, it has been suggested to use #offline as well as tiwtter hashtag

<mwbrooks> dom: makes sense, thanks!

<mwbrooks> dom: yea, #offline is already a popular tag. #offlineweb it is

<anne> yes

<anne> need developers to speak

<blizzard> anne: did we get any actual developers?

<blizzard> anne: I've interacted with some, and that's part of my feedback!

<blizzard> anne: but I was hoping that some people would show up

<darobin> blizzard: I see at least two webdevs in the room

<blizzard> yay two!

<filmaj> +1

<blizzard> 4% developers

<darobin> it is conceivable that I may not know everyone :)

<blizzard> indeed, me either

<henri> We should transform the workshop in a hackaton. It's saturday after all, and we might be enough to have an offline app tonight.

<anne> wycats is one

<darobin> also, I'm not counting people who do standards and develop -- if we add them we get quite a few more

<anne> blizzard: ^^

<dom> I consider myself as an amateur Web developers; I've used html5 manifest in one of my app (http://www.w3.org/2009/cheatsheet/) but found it difficult to use for more dynamic apps

<darobin> +1 to henri

<darobin> I have a flight at 6 anyway, so hackathon sounds great :)

<shepazu> (I'd like to note 2 points later: 1. unique ids per installation and protocol/api to talk between instances of an app; 2. applying resources to HTML file via manifest, not via <link> in HTML page )

<shinypb> @dom I like the cheatsheet.

<dom> thx :)

<darobin> yes, the cheatsheet is good stuff

<wycats> blizzard: I'm a developer

<jfmoy> darobin: six in the morning? that leaves us a couple of hours, let's do it

<dom> Web Apps as First Class citizens

<dom> HTTP optimizations for ApplicationCache updates

<dom> Sung-Ok, You, Infraware paper

<jfmoy> If people are interested, my notes in real time: http://www.evernote.com/shard/s11/sh/88074d12-111c-4e09-b148-5fa21984caf1/2392391d70615322f65b6592881a9c4a

<wycats> My "quick-fix" proposals: https://gist.github.com/1341809 (I didn't learn about this workshop until after the deadline for papers)

<dom> Offline Web Applications for Disaster Relief

<henri> jfmoy: darobin: An offline wiki could be a great app, don't you think?

<stakagi> http://www.w3.org/2011/web-apps-ws/papers/KDDI.html

<wycats> unfortunately only people who submitted papers are allowed to speak

<wycats> (now)

<darobin> jfmoy: yup, 0600. It seems to me like we can solve this workshop easily with a hackathon following the JFDI methodology. We could just expose unfettered disk access to arbitrary web sites, that'll give you offline alright

<anne> I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=14702 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=14701 on HTML5

<dom> well, given the speed we're going over the papers, your turn should come up soon, wycats

<anne> to make appcache easier to use

<wycats> dom: I didn't submit a paper :(

<anne> mostly based on what tobie & wycats have said

<darobin> wycats: we said earlier that we'll open the floor to people who didn't submit papers

<wycats> darobin: hope so :)

<ernesto_jimenez> wycats: you'll be able to talk :)

<darobin> I see no reason why you wouldn't talk

<ernesto_jimenez> the paper order just gives some order, I think

<wycats> ernesto_jimenez: awesome :)

<wycats> anne: +1 on those tickets

<wycats> anne: if we get this stuff done, then we can talk about a "system and method for dynamically storing resources for offline available using a scripting interface"

<wycats> oh shit is that a patent

<wycats> :p

<jfmoy> Please don't modify my note, got a conflict ;)

<darobin> james knows how to use a mic

<dom> darobin, that's because he actually didn't need one :)

<darobin> :)

<darobin> I think the thing that has most improved with telcos in recent times is that they now send their devs rather than their suits to such events — and that's progress

<ernesto_jimenez> darobin: that's nice, isn't it? xD

<darobin> ernesto_jimenez: yes, it really is :)

<dom> [one way I thought of working around http headers difficulty was to use data: url as manifests, but that didn't work last time I played with it]

<darobin> yeah it's quite amusing that appcache is the only part of the HTML stack that actually pays attention to media type, and that that's very precisely a case where it's a huge pita when developing

<wycats> I wonder why we can't support <img src="foo" cache>

<wycats> and maybe a <manifest> tag for resources that are not referenced in the master resource

<filmaj> maybe add a <manifest> to the config.xml?

<filmaj> web app, offline app, native app, the differentiating lines between these are starting to blur

<wycats> why not config.json

<wycats> BAM

<filmaj> D:

<Zakim> chaals, you wanted to speak about his paper

<inserted> ScribeNick: dom

Charles: Widgets and applicationcache are doing similar packaging stuff
... we need more complex use cases
... Web apps get deployed in many different way on the Web

<filmaj> or even straight onto mobile platforms ie. phonegap

Charles: via http, via email, via broadcast

<filmaj> yeh

Charles: Many people have indicated that appcache is broken
... but widgets work well - although we have stuff that we know we want to add
... we're also happily and successfully using them for other applications (e.g. opera extensions)
... while I think that AppCache is a valuable part of the platform, it seems full of problems

Matt_Womer: my concern is that by trying to hit parity with native apps, we start losign some of the advantages of the Web
... e.g linkability, good UI, etc

non-paper based presentations

Wycats: I've looked at AppCache, it has two adoption problems
... a new mime type: most dev can't change them
... second problem, appcache makes it very difficult to have an app be just as usual while online, and be well cached while offline
... I think it's good that appcache is atomic, but there should be another mechanism

<blizzard> wycats: I want to talk about the "use the cache when you're offline" thing

<wycats> blizzard: cool

<wycats> I said that the atomic feature of appcache is good

<blizzard> wycats: do you think that's something that app cache has a role to play there at all?

<wycats> and that programmatic control should probably be a different API as a result

<blizzard> wycats: Feels like a general browser feature

<blizzard> wycats: but we should talk

<wycats> blizzard: it's essentially the same feature as app-cache *when the user agent is offline*

<wycats> blizzard: cool

<blizzard> there is a line

<darobin> look, another telco sending a developer

Jean_Francois: +1 to appcache being a pain to develop with, to debug

<darobin> we'll end up liking these guys :)

Jean_Francois: I would like to talk also about better integration of Web apps into OS
... one of my concerns with Web apps is that the user has to launch the browser to start the Web app
... it sounds like something that would be easy to achieve

<chaals> [Widgets are not a perfect solution. But they have some nice features, and they aren't a horrible broken experience, and it looks pretty clear how you extend them to do the things we want to do. Which makes the basic approach seem sound].

Michael_R: I wrote PouchDB (?) and Offliner
... turns a couchdb app into an appcache app
... also a couchdb and node.js contributor
... my concern is why appcache is so far away from http caching

<darobin> https://github.com/mikeal/pouchdb -> PouchDB

<blizzard> hehe pouch

Henri: I suggest we turn this day into a hackathon to detect the actual problems with appcache today
... e.g. a off-line wiki server to figure out the actual problems
... my intuition is that a combination of localstorage and various other javascript api we can make this work

Dan: sounds like an interesting idea
... we hadn't thought about having an hackathon during the event

<chaals> ernesto_jimenez, You are right that developers want their online app to work offline. Here's a proposal: link your online app to a config file, and it can be auto-converted into an offline-capable app, or an installed app.

Dan: this could be done in the room at the back of this one
... my only concern is that we might remove some of the opinions from the discussions
... but if people are interested in that, feel free to do that

Kepeng_Li: an important issue for offline Web apps is how to exchange data between the app and the server

<chaals> (I realise that isn't yet perfect, but as a starting point there are a fair few nice bits in it. Blending in the appcache manifest, so you don't have to replicate the widget model of keeping all the files inside your root directory, is about the first thing I would like to do...)

<James> Hackathon a great idea; we all need to feel the pain

Doug: talking about manifest, it could be used to apply resources to a page rather than linking them from it
... I'd like to have unique ids for a given installation of an app, so different instances of an app can be pointed to, and talk between instances remotely

Sicking: I just want to say we need to do this as an iterative process
... whatever we come up with, it's very important we gather a lot of feedback before we try to nail down anything

<chaals> [Yes, two installations of an app need to be able to talk to each other. This is about the most common problem I find developers having with widgets, and really needs to be solved]

yosuke: I'm one of the co-chairs of the Web & TV IG
... I'm interested to talk about non-connected TV sets that can receive data from broadcast only

John_Foliot: I'm a Web accessibility guy

<darobin> [having two apps talk together: intents/activities could at least partly do the trick]

John_Foliot: I'm interested to reach out to framework dev, etc to make sure that they're accessible to person with disabilities

___@: I'm part of a company that builds a lot of mobile Web apps

scribe: we're very interested to improvements to manifests
... it's very hard to test it, and develop with it while updating the content
... the whole world of caching content still needs to be figured out properly

<darobin> someone needs to invent a way of tagging objects dynamically

<darobin> yosuke: I wonder about the broadcast delivery case — normally an ESG should be able to pretend that the delivered content is a local app, update it as needed, etc. no?

<matt> scribe: Matt

Chris: Use cases and UX are the same to me.

DKA: I see use cases as higher level. For example, disconnected mode while in a disaster zone. That's a use case, but not a lower level use case like listing the current apps available to you.

Balaji: Need to discuss convergence, are installed apps required?

James: I'm disappointed that there are only three in the Developer Experience category. Those guys are dying out there.

??: Life cycle covers DX too.

José: When we are asking for fixing app cache flows, we are talking about the developers.

DKA: Looking at it through the developer lens is slightly different than lifecycle.

chaals: Let's start with the use cases. What are we trying to do? It's not a single flow. These are topics we should have in mind all the time. Who is it for? UX Who is going to do it? DX We need to understand these.

DKA: Do you want to start with Protestors, or listing current apps on phone?

chaals: What are we trying to achieve? Enable all sorts of different things. The more we understand what they are the more we see if we're enabling them. We start with 50 use cases and build some idea of what we want to do, then throw out ten? What does it cost to add five back in?

DKA: A session in the afternoon where we focus on Use Cases.

chaals: Start with use cases.

JanL: If we directly look at a solution like app cache, it assumes caching abilities, but some use cases involve not sending things over IP for instance. We need to look at use cases to figure out the next step.

José: A top down approach, this is a technical workshop.

José: Could have another session for use cases instead.

DKA: If people want to split that's fine, but I think a single stream is good.
... Sometimes when you break out you just end up with like minded folks arriving at consensus but not across the breakouts.
... Anything missing on the board? Or not explained?
... We will put this stuff into Google Moderator as a mechanism to prioritize and a tool to organize afternoon discussion.

<vgalindo> leaving the workshop to go back to europe. ciao.

<henri> Hackaton starting

<henri> Join the Inception room at the back if you want

<magnus> An offline wiki, kind of http://tiddlywiki.com then, but with a server?

<bryan> ScribeNick: bryan

matt: using Google Moderator thingy

<dom> http://goo.gl/mod/HHRR

matt: goto the url

dom: suggestion - vote on topics that will be productive for today

matt: add to the moderator page, only as last resort create a new one

dan: by 1:15 we will wrapup on use cases

<shinypb> use case: use appcache to speed up online apps, particularly by deferring re-downloading of newly updated but non-critical resources until after the page has loaded.

dan: if you have ideas on granularity of use cases come up and make your case

dom: not too high use cases, consider what these tools are trying to solve as use cases
... use of Webapps when offline, increasing cache performance, making it look like a native app
... making them distributable
... beyond HTTP

noah: covered by installed app look and feel? to make them practical for users to install and manage similar to native apps

dan: does anyone disagree with "installable" being part of the discussion here

tobie: hostable applications is something important to consider

chaals: installable apps are important, but plenty of cases where you don't want to install the app - e.g. making it installable or not

<blizzard> put me in the q: queue!

dan: capturing the action of the user that they are taking possession of something
... what do you install, a link, a package, etc

<Zakim> wycats, you wanted to present his views

<magnus> Installable could be considered a special case of hostable if there is a local host taking the role of managing the lifecylce

dan: that deserves its own use case. there is an emotional aspect of having something on your computer

doug: the trust you give to the app when you install it

<shepazu> and your expectations about what the app can and will do for you and to you

mark: appcache gives developers real control over what is displayed on the page, and would like to focus on that

<magnus> Maybe we should consider a more flexible notion of installable using terms such as "docked" as we may need to ensure that the app is not cemented to the application but can safely be possible to distribute itself between online/offline and cross multiple devices

chris: use case of installing an app is not dependent upon the mechanism - the question is whether we expect to use appcache for installing an app - its different re widgets or zip files

<Zakim> noah, you wanted to argue for install

noah: re not focusing on installable things, we should build abstractions based upon what users recognize, e.g. when I press this I expect it to work until I undo it
... if you ask the user to manage local stores, the abstraction is wrong. you need to describe the need in terms they understand
... going that way you can put emphasis on the abstraction of the app, toward what users expect

<magnus> "Installation of Application being a positive and natural step for users is a myth!!!

<magnus> User like to conenct with their data, installation maybe be a necessary evil of that process

dongyoung: we should discuss installable webapps. most user understand the concept that the user is in my device, and should run offline

<magnus> s /conenct/connect/

<anne> (without Google you're also not going to find it...)

dan: (didn;t catch)

<magnus> "Dockable" applications rather than "Installable" (but might be a matter of definition of course)

chris: install experience has some component of a relationship with a website. two use cases: install as an offline app, and opportunistic caching. making a website better by agresively caching is a performance objective for websites as users normally expect them. I would like to use appcache as a means to improve performance of websites.

nvbalaji: +1 to noah's comment. we can build a better security framework around installation.

dan: that's an extra use case - maybe related to making a webapp look like a native app. linking permissions to an installation step

<dom> network resilient Web apps?

<anne> dom: needs more buzzword

tobie: the offline term bothered me when considering the workshop. we need to think about performance, e.g. where the network performance is an issue. data at facebook proves that when users are asked for a lot of choices up-front this impacts their experience.

<magnus> +1 to chaals

<dom> anne, cloud-based strategically network -resilient Web apps?

<magnus> why install f not needed

<anne> o_O

chaals: users will ask why should I have to install an app to get to privileged resources? if my business model says I keep all your data and you have to be connected to use it, we also need to be able to access the same resources for those apps, and it should be the same experience. And don't forget that the state of the art in this area is still pretty simple and not very good

dan: we have to be able to articulate the offline vs installable webapps as different use cases

chris: re security and installation - don't want to talk about it here. we will not solve that here

<michaeln> "install" for the web seems more about granting rights than caching for offline use

dan: getting to consensus on security and permissions etc as a discussion for today

<filmaj> +1 to michaeln

bryan: we should discuss the origin (i.e. where an app comes from and how that relates to the Web security model) for side-loaded webapps and widgets

<anne> michaeln: should they be tied though so the user is guaranteed to not be greeted with the browser's network error dialog when on an airplane without wireless?

chaals: we dont need to talk about connecting to things online. when you install the app though you may lose access to those things, and access to content should be equivalent

vidhya: being able to find and connect to an installed app - does this mean knowing that Dan and Chaals have downloaded this, and I want to connect to them thru the app?

chaals: yes, the first is true, but also if I have downloaded two apps and I want them to talk, there is no common way to do that

dom: web intents?

chaals: maybe, but "web intents" isn't a *use case*, it is a "potential solution"

bryan: the one API to rule them all...

<anne> 11 is web intents?

<michaeln> anne: can you grant rights w/o "installing"?

dan: a lot of the topics hitting here are related to hackathon update, and that is our top topic on moderator - wait - check - fixing appcache flaws is #1

chaals: would like rather than fixing it, think about what it can/cant do, note that some will fix it, and not go so far into it that it would hijack the discussion

dan: it might be useful to spinoff into a breakout

<blizzard> dom++

dom: we need to find which of the use cases we have identified are supported by appcache and what fixes to it are needed for those use cases

dan: talking about adding features?

dom: no if we focus on appcache, look at what it enables today and how that relates to our use cases. e.g. using appcache for offline web apps is a big pain today

dan: one of the things is how appcache is not possible for some developers to use

tobie: two strategies - the easy fixes and address problems in current browsers, and at the same time have a long-term strategy discussion on what more we need

<anne> long term is one and a half year? sweet

tobie: crucial to fix it as a short-term strategy

<blizzard> https://etherpad.mozilla.org/appcache-notes

<blizzard> that's my full list of notes about app cache

<blizzard> stuff that needs to be fixed, added, broken, experience changes and posts about iut

<blizzard> it

jose: two types of problems - implementation (e.g. not being able to reset, resources are not refreshed (developer education or spec clarity)), and also interaction with regular cache - we have two different mechanisms that makes it difficult for devs to use these technologies

<blizzard> (very firefox-focused, sorry)

vidhya: in the short term we need to fix the specs, and have a strategy discussion. if we dont fix it, it will take even longer for developers to really start using it

<blizzard> anne: are you talking about the difference between install and opportunistic caching?

<blizzard> anne: they are different!

<blizzard> anne: (in the doc)

<blizzard> err, etherpad

noah: the first thing to do is to gather requirements, what cant be done with it today, and see what can be addressed here from that

adrian: would like to hear about the problems with appcache

<nvbalaji> What exactly do we want to achieve in this room?

<anne> blizzard: yes

<anne> blizzard: I mean that based on the manifest= attribute you don't actually know whether you are dealing with an "offline app" even though HTML5 suggests you do

chaals: propose that we have 1/2 hour discussion on what it does, what it should do, and use that result to determine how an improvement will help the use cases

<anne> blizzard: so a UA can't e.g. list pages using manifest= on a special page when the user opens the browser when offline

<nvbalaji> +1 chaals

dan: would like to constrain the discussion to what it is supposed to do, rather than things we wish it to do

<blizzard> anne: I'm not entirely sure what you mean, should discuss with voices

<nvbalaji> It's important that we do not disappoint Appcache folks

dan: the point is what is broken is part of the bigger discussion

<blizzard> http://www.stevesouders.com/blog/2011/10/03/improving-app-cache/

<blizzard> that's the link

<blizzard> also the list of urls in the etherpad

steve: it would be good to come to consensus on these issues

tobie: recommend to read the points in the paper about appcache flaws

<matt> Tobie's paper

noah: do people feel we have enough clarity on the requirements of the workshop?

dandruta: we need to consider the use cases in addition to the pain that developers have with appcache

<blizzard> I haven't read it

<blizzard> :(

dan: suggest we need to start with the issues with appcache

<nvbalaji> chaals+

tobie: presents his paper
... the point of appcache is to enable app use when offline
... but a number of very small flaws
... appcache is designed to allow offline web apps that can access online resources when connected

<chaals> [+1 to "you need to be able to update the manifest easily"]

tobie: one of the major flaws is the auto caching of pages when you visit them. this means content is always stale when the user opens the app
... in mvc cases where the markup is chrome, this makes sensew
... but it should not be the only option
... the ability to ask for caching of all manifest pages
... 2nd problem is the way that the app updates itself - the manifest file being the key breaks fingerprinting, and results in cache-busting

<chaals> [+1 to "Simplify the process of adding manifest/config/etc metadata of different types *including* manifest"]

tobie: the manifest being identified by URL, prevents developers from busting the cache
... if you want resources to be updated, you have to change the manifest (e.g. comments)

<dom> we could keep the url as the identifier, but add a manifestVersion attribute or something?

tobie: changing the manifest file name
... but not nuke the cached contents

chaals: you may want to nuke one file, but keep the others

<anne> so you want something like:

tobie: the current cache is used as the source for updates and if you change the manifest, it feels like it busts the cache and you have to download everything

<chaals> [+1 to "you want to be able to get stuff across different networks"]

<dom> anne, that'd be another approach to it indeed

noah: I want to persist content, and when I change the manifest I want to update only the changed content

tobie: looking at the use cases, there are things that can be improved

<blizzard> I'm kinda confused

noah: minimal disruption to what is deployed could be a 3rd requiremet

<chaals> [I prefer tobie's approach of a slightly bigger syntax change that allows the semantic change to work nicer, instead of trying to continue working on the existing syntax. But that's a bit too detailed for this discussion, I think]

tobie: 3rd requirement is to put appcache on CDNs

<blizzard> sigh

tobie: to recap, the autocaching of master entries can be opt-in - i.e. an online app is online, and not the opposite

<chaals> [yeah, I think CORS might be able to deal with the getting info across networks too. Although I haven't thought it through yet. Anne, have you thought about that already?]

tobie: 2nd addressing the cache busting issues

<dom> [I'm not sure if Tobie's fixes include "get it from online unless you're offline"]

tobie: 3rd addressing performance issues e.g. via CDNs

<blizzard> I still don't understand 2.

<blizzard> I will need to figure that out

<anne> [Not sure if CORS can be tied to it.]

<blizzard> tobie: you should find me later to explain the cache busting problems to me

dan: is there anything to disagree with or not covered

<matt> [[1. Flip model to allow online applications to be online. 2. Fix fingerprinting/cache busting 3. make it work with CDNs]]

<chaals> [2. Enabling live incremental changes to the manifest]

jonas: one thing more is that the manifest is served with a specific MIME type. it is exceedingly hard for devs to change headers even content type - this excludes 90% of developers - many dont have access to the servers. if we ignored the content type of the manifest file we could increase the number of developers that can use this

<michaeln> tobie: i'd like to understand your cache busting problems better too

peter: going over quota

chris: thats different, some consistency would be good

dan: what is you run out of space?

<matt> Chris: Only Opera and Safari ask to store and have limits

<blizzard> matt: opera and firefox

<chaals> [I think Anne and Noah had good explanations about what 2 means - it's about functionality not (at this stage) figuring out the exact spec for it, and a great example is to stop caching a single file, but maintain the rest of the cache. The point about fingerprinting is that the current common technique for the existing syntax is to change the URL of the manifest, which is an ugly hack, but even that doesn't really work at the moment]

<matt> s/Safari/Firefox/

boris: anyone thought about the game use cases, e.g. instant on - appcache loads all at one or not at all.
... storing large amounts of assets, you dont know how far along you are

<chaals> [+1 to being able to dynamically load stuff in a more intelligent way than "all at once" - which I think is related to 2. from tobie. If you could dynamically change the manifest, you could already control what you load when]

<tobie> michaeln: I'm happy to explain it in person.

<matt> [+1 to IndexDB with Large File Support]

<chaals> [-1 to using indexedDB for something that is really easy to handle in appCache, if you can just tweak manifest. It's much simpler - better Dev Experience]

<tobie> michaeln: it's very difficult to explain without going through the whole process of how AppCache works.

chris: we should restrict appcache for storing assets - you can actually add resources on the fly and iterate on them, e.g. indexdb which is a better model

<chaals> [+1 for access to the file system]

<matt> bryan: Outside of the browser space we need to be able to store stuff for offline use. I could quickly fill 5mb storage lintit. We need file system support.

<richt> file api and file system api are different things.

jose: my basic use case is use my web server when online and use appache to get my content when not online

<blizzard> file api lets you get to resources, but those resources could be in a local file or indexeddb or websql or whatever

<blizzard> or even in the app cache!

bryan: access to the filesystem is essential for offline apps to get beyond the browser limitations

@@@: ability to store more content than browsers will allow - what is the direction

<matt> s/@@@/Jean-Francois?/

jonas: there is no hard limit except 5MB in localstorage. IndexedDB with file support is coming and already supported in some browsers. eventually we will have support for large content store with direct file access and very fast.

<matt> s/Jean-Francois?/Jean-Francois/

ernesto: we need to be sure that devs who want to use appcache for assets that are needed but the dev doesnt want to have to pull them from the server, can use appcache for that purpose since they dont have to use other complex methods e.g. storing in localstorage or file APIs etc

<michaeln> +1 appcache should focus on bootstrapping more than storing dynamic media assets... filesystem and indexdb can work for that

chaals: i want to use appcache for doing this "storing and managing files". the other thing is I want to know just how much space Ive got, and negotiate for more.

<nvbalaji> +1 chaals for query on cache space availability

dan: additional points?

<chaals> s/. the other/, rather than some more complex technology that works better but is harder for developers.

<anne> blizzard: I can explain the case for #2

jose: recommendation from the workshop to revisit the appcache design?

<anne> blizzard: the reason is that you want to pretend the manifest resource exists for a very long time so the browser will get back 304 all the time

dan: we will identify the recommendations for the current appcache feature

<anne> blizzard: but then sometimes you do need to update it but you can't because it is "permanently" cached

<anne> blizzard: there's a technique called "fingerprinting" in which you basically change the URL when you change the resource

<anne> blizzard: but that technique cannot be used for manifests because it's identifier is the URL

dan: adding large assets to the use cases

<anne> blizzard: and if you use a new URL you have effectively a whole new thing and the browser will not reuse existing cache hosts

bryan: we need to keep mind that appcache is not usable for files that are created / updated as part of the app

<blizzard> anne: I'm a little surprised that it doesn't keep the resources and check them

<blizzard> anne: ok

<smus> any additional info on large file support for indexed db beyond http://goo.gl/XVXsp?

michael: programmable cache can be looked at as a way to handle dynamic cached content

<lgombos> http://www.w3.org/TR/DataCache/

<blizzard> smus: ask sicking

<anne> blizzard: http://code.google.com/speed/page-speed/docs/caching.html suggests URL fingerprinting is popular and at the face of it seems incompatible with the model appcache has

<chaals> [+1 to anyone who said it was a bad idea to add another cache mechanism instead of a commonly required improvement to the existing one]

<anne> it, it*

<blizzard> smus: https://bugzilla.mozilla.org/show_bug.cgi?id=661877

<blizzard> anne: ok, got it

<tobie> blizzard, michaeln, sorry I butchered explaining the fingerprinting issues, happy to explain it again. anne, looks like you understood my issues, care to join us?

<matt> Data Cache

adrian: the data cache use cases were different from appcache and the work was put on hold but the work can be taken forward if there is interest

<blizzard> anne: I didnt' realize that changing the url of the manifest file would blow away all the resources

<tobie> blizzard: great, looks like this is cleared already.

<blizzard> anne: sounds like it just needs to be more opportunistic

jonas: agreed that there were differences, but they are some things that could be added to appcache to bring them closer together

<blizzard> tobie: thx

jonas: we can have an extra section in the manifest, e.g. deliver requests to a javascript file

<anne> blizzard: I guess you could instead use the manifest URLs as identifiers or some such

<anne> blizzard: instead of requiring more syntax

chris: other feedback is that there is an assumption that if one resource fails, the whole cache fails. that is bad and should be changed.

<anne> s/manifest URLs/master entry URLs/

<blizzard> anne: *nod*

adrian: to some that is a feature. when the goal is that the cache is consistent due to dependencies, an incomplete cache may be undesirable

chris: an installable app should be coherent, and opportunistic cache can be flexible

<michaeln> +1 jonas "deliver request to script" handwave

noah: cache has pretty defined meanings in computer science, and we need to keep that in mind. tradeoffs in coherence vs variability need to be considered. very complex replication algorithms can result. cache works badly where correlation between multiple assets needs application-specific replication. look at the literature but pick a simple point in the space or be prepared for a lot of complexity.

convergence

matt: we are all appcache-heavies in this room... but now something about widgets from marcos

marcos: widgets are relevant, as quite a few are working on widget engines. widgets are primarily a packaing format and API for the manifest.
... its pretty simple, e.g. by Opera and for extensions e.g. in PhoneGap
... they haven't gotten as much use yet, usage hasn't come up that much though there have been a lot of widgests developed and downloaded
... re appcache, widgets and appcache serve different purposes, also other approaches such as APK-based approaches that use WebView
... re the questions such as origin, access to resources in the package e.g. via widget:// using XHR to items in the package, etc there are open issues
... I would be interested in talking about these issues e.g. at the next break

<nvbalaji> +1 Marcos for common packaging manifest

marcos: a larger question is the different paths e.g. open web apps, chrome web apps, widgets... can we get some agreements on a convergence path? we did the widgets stuff and have put that on the RF table, and we should do that convergence in webapps or elsewhere in the near future

<anne> tobie: blizzard: I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=14704

<tobie> anne: ty

dan: re "something wrong on the internet..." a lot of people have told me that we are not interested in installable webapps, we have appcache etc, and a year later we have different technologies being deployed for exactly the same use cases (installation)
... maybe we have come the same place now, via different routes, and now are in a place with different technologies for installable web apps. are we good, or do we want to converge?

<nvbalaji> +1 dan for talking about

matt: group hug for dan

jan: from ericsson position, we needed a technology for installing apps, and have found widgets to work. is it a business solution to use approaches that are specific to the browser, to not have a universal solution? why wasn't a unified solution sought in these cases?

chaals: we tried it and a standard has worked out good for us. but the question is why did others not choose this approach - can others explain?

dan: maybe one thing is to consider stuff in the widgets specs that are extraneous, something that can be pared down

chaals: config.xml packaging is one, json as an alternative
... a nice features is localization, built-in to the packaging, enabling self-localizing multi-lingual applications
... a missing feature is something appcache provides, the ability to run online and then move offline
... widgets cant constrain where your assets are kept

<darobin> sicking: http://colinm.org/language_checklist.html

chaals: if widgets are going to be part of a solution that works offline and online, it needs to address cases in which all of your assets are not in one directory under the widget
... there may be another missing piece re how you repackage into a different directory structure
... also inter-widget messaging is a limitation
... but as before they are not hell on earth to program they are nice, and something to consider as part of a better solution

dom: one thing to focus on, is anyone interested in convergence by implementers in this space

vidhya: is there a view in this room that we need a standard container?

matt: do you think converging these things is a good idea?
... anyone against looking for a convergence where you can use something that grew out of widget and appcache in the same solution?

dan: reforming the question - do we think that installable web apps is something that we should be looking at for the next gen of appcache?

dom: asking the question: is there space for both, or is the overlap so big that we should converge the two - speaking of offline web apps
... one thing we both agree, both enable offline web apps - do we need two technologies

marcos: I want a calculator I can build install and run on my computer and be done

tobie: adding web developer perspective, the facebook platform for html5 apps. if they want the apps to run all over the place, multiple manifests must be created and this is ridiculous - they should not have to create multiple different manifests

noah: use cases: as a traditional web app, lots of uris for resources that come down and may be installed for offline use
... next is the marketplaces, using this as an approach to address the fragmentation
... another us putting an app on a usb key and installing it without dependence upon uris

<nvbalaji> +1 tobie for common manifest

noah: how do I put those together into a common framework

marcos: they are addressing different things. apps may interact with the web and distributed though different methods. the use cases are clear, and the number of phonegap apps being developed proves there is a market for installable web apps

jan: good point re installation of webapps is a ua issue. each web store will have their install method. merging with native installed apps and those coming from the web. one issue is how to identify when a webapp is being installed vs a native app, and the security aspects of that. a first step may be to get the packaging addressed, and later look at the lifecycle aspects.

dand: giving an indication to the user that something is being installed via appcache, vs the experience of installing an app such as a widget, we need to converge

chaals: we could in response kill off one, or converge the two
... from Opera's perspective, we dont think the first one will be supported, and we will keep developing it. we have no interest in killing off appcache, and will keep developing it. the same developers and markets are being addressed, and we will provide guidance on how to solve the problems using appcache or widgets
... that would be more constructive
... otherwise we can fight over the two technology stacks, and that will be quite expensive

dan: its worse, as a developer I have to do multiple things beyond all that

tobie: nitobi has good experience with widgets, comments?

adrian: looking at the different technologies/ideas/concepts would be a good idea. a goal should not be breaking changes to convergence, convergence to the detriment of all that exists should be avoided

phil: phonegap's use is a superset - a different way to ask this is what is the superset

<matt> bryan: We're very interested in installable Web apps -- thus the focus in our paper -- we launched this week the first global market place for Widget based Web apps through WAC.

<matt> bryan: We expect that to expand in the future, to be a viable platform for developers to use and we're putting all of our effort into widgets.

<chaals> [disagree that widgets is a superset, although there is a lot of overlap plus a bunch more functionality in widgets and some things that only appcache can do today]

<matt> bryan: We're interested in all of these things converging to support all of the diversity in the market, and to give developers fewer ways to do the same thing. They need to see new ways of doing things, but they need convergence because it's hard to get anything done today.

<filmaj> both technologies describe things about apps; define metadata

<filmaj> in my opinion merging them makes a lot of sense

jose: agree with bryan, confusion will reign if we dont pursue convergence

dan: can someone from W3C talk about the state of widgets and what we see is next

doug: its drawing to a close ....

marcos: as editor, its's done

doug: from the staff's perspective, we would like to see stronger support - and that will not be predicated on it being based upon widgets

dan: is it possible for bringing appcache into webapps and consider it with widgets as the next standard basis

adrian: speaking for MS, the last call comments to appcache we hope will be addressed - the html wg is looking at html after 5, and they will be put into the wiki and maybe webapps in the future

<adrianba> Wiki for HTML.next -> http://www.w3.org/wiki/HTML/next

boris: 2 points - the two models are quite different. for widgets you don't have an initial loading of the cache for example

dan: should appcache have the ability to allow the user to install the app on the device?

noah: you need to ask devs if they want that, and does appcache give you what you want for that

chris: that's not appcache driven its ua driven

<smus> noah: do you have a link about the iphone behavior you describe?

dan: we heard about adding a hint indicating that this is an installable app

dom: there is an html5 "application name" meta tag
... a point-by-point comparison can be done

@@@: we already see different approaches, and a common approach would be good - fragmentation is bad as its good for developers to have one way

<dom> s/@@@/jean-francois/

<matt> bryan: I would say that we need to be careful about converging different approaches to serve the exact same thing but still remain different approaches.

<matt> bryan: AppCache is about optimizing caching. Some implementations make use of this to make things installable.

<matt> bryan: It doesn't tell you everything you need, like what icon.

<matt> bryan: Having these things converge and yet remain with different purposes doesn't make sense for developers.

bryan: we need to enhance appcache for what it was intended and not converge different technologies for the same purpose which nonetheless remain different approaches that complicate developer tasks

tobie: developers want something that is not bad to use, and is one approach - we should avoid making developers unhappy

<tobie> bryan: I like how you clean-up my language. ty.

chaals: poll on continuing discussion or splitting off and addressing convergence

<filmaj> Dan just nailed it

<chaals> [wasn't a poll, it was an attempt to get an answer to the question of whether talking about convergence was popular so as to say 'yes, converge' or to say 'no, we are not interested, let them fight it out']

dan: from a developer perspective, why are we here - trying to overload these technologies - we need to focus on the developer's ability to use methods to do the things that the developer wants to do, and we naturally has split them up - I am advocating for convergence

lifecycle

<chaals> scribe: chaals

wycats: Ended up doing typical JS stuff. First hour was pretty instructive.

1. nobody had a server, so building an app like an offline wiki page was tricky.

scribe: couldn't serve a manifest file.
... Had issues where managing the caching of the cache manifest was unclear.
... Couldn't pretend to be in online mode.

<bryan> sounds like typical issues I run into as well...

scribe: Talked about how we'd like to be able to add a URL to the cache.
... I wanted to be able to bootstrap a cache manifest, and we kept wanting that.

RB: Would be simple to have eg a cache attribute to get stuff cached.

<bryan> +1 to bootstraping the cache from local files

DKA: Still working, towards a demo?

RB: No, going to maybe propose the cache attribute. Make a specathon.

Lifecycle management.

<nvbalaji> Does Lfe cycle management make sense given that we do not have consensus on convergence

DKA: Think that relates to user experience...

[don't think we need convergence - life cycle happens in each world already. Might no longer be the top topic though]

JL: We used widgets in our life cycle, not sure what W3C's role would be there.
... in OIPF we described how to install, update, remove widgets and get a list of the widgets that are installed.

<nvbalaji> But we know how the life cycle, if applicable, happens in each world

JL: Have 3 use cases - coming from a trusted source, coming from an identified service provider, coming from "anywhere else" with no direct trust.
... Can we get something from W3C for this?

NVB: We know how the lifecycle works in each world. If we're not looking for convergence, what's the question?

MC: What is the use case - what do you want from the life cycle?

??: Problems discussed are related to stages in a life cycle of an application - online? cacheable? etc.

scribe: we may not have to look at this as a whole, but look at each piece.
... Life cycle is an important aspect.

<JanL> http://www.oipf.tv/docs/Release2/V2.1/OIPF-T1-R2-Specification-Volume-5-Declarative-Application-Environment-v2_1-2011-06-21.pdf

<JanL> this is the link to what I referred to as OIPF widget or application lifecycle

MC: Sure, but concrete example? Let's say I go to a mail app, and it caches some enormous data, and then I want to let someone else have the phone. How do I clear off the cache?

<JanL> refer to section 5

DKA: Isn't that an implementation detail?

MC: Exactly.

<nvbalaji> chaals: Well, I do understand life cycle is important.But specific technicalities for each world could be discussed in those forums. Again, I am not trying to play spoilsport here

BS: a lot of these issues are like that. There may not be anything W3C specifies explicitly for that, but they are important things for people who want to manage the life cycle. We have to document how this is done, without having to write a spec for it.

DKA: Want to pick up on best practices. I'm hearing that a lot of problems are from developers using a tool or spec in the wrong way.
... e.g. what is the right technology for games to load up lots of assets.
... is there a need for a best practices document around the use of these technologies?
... MWBP didn't go into great detail about how to do it...

Dom: Think we need to fix them before trying to explain them.
... Doesn't help to spend effort on describing how to use something that is broken.

CMN: Short answer: No.

MW: Why wouldn't we want to write up best practices for using what we have?

<matt> chaals: We could have an effort for lots of things, but W3C should probably fix app cache rather than write about it.

Bryan: Think other technologies related (local storage, indexedDB etc) are part of the problems we have.
... these are all topics for offline web apps.

NM: I thought this was about describing what the user sees and what the user expects.
... don't think appcache is speaking to the user yet.

AvK: It is transparent to the user. Think that is better

NM: Maybe. I don't think it gets up to the level where we can do this yet, so that's an answer.

User experience

MW: Is there anything we can do to improve the user experience, how apps interact with each other, how do we improve performance?

DKA: Also talked about the question about how to get into priveliged resources?

<matt> chaals: I fundamentally disagree with the idea that installed apps are installed and the user is done.

<matt> chaals: With the Web platform we are trying to make lots of cool capabilities. Let this app do X, and then it can do X. Not have the apps ask "Are you sure you want to do this?"

<matt> chaals: OTOH, if it's "take money off my phone", you probably want to say "please ask before you take money away" instead.

<matt> chaals: It would be helpful to have the model used online to be the same as the model offline. People learn familiar things better, even if it's bad things they are learning.

<matt> chaals: It should be the same way, off and on.

MW: There is a case that installed apps implicitly have permission to do stuff.

s/MW: There is a case that installed apps implicitly have permission to do stuff.//

i/chaals: I funda/MW: There is a case that installed apps implicitly have permission to do stuff./

ABate: Don't think anyone says installing an app should give you all possible permissions, and if they are they should stop.
... but there are things you want to allow, having installed an app.
... e.g. same origin policy for an app that connects you to facebook and vkontakte and mixit.
... In an open web app, we don't want to change same origin restriction (without CORS), byt maybe in installed app it is OK

CB: Has to be context sensitive. Users often dont know enough to give permission up front, but there are cases where you do. Think it needs to be possible either way.
... Think the model we have at the moment in web apps works out.

RT: Agree. User experience is a broad area and what you do depends on context.
... We were recently designing something in two places, understood the principles, ended up with something similar. Important not to codify this stuff too early and too specifically.

?? Nokia: Editing spec about permissions for features. Think you want to prompt for some permissions at install, but we have no spec to do so.

DKA: If you need to prompt a user for something, there is no specified way to prompt.

CB: [scribe missed it]
... educating users to understand the lock icon was hard, and slow, and expensive.
... Green bar for EV certs is widespread. Having understanding and working together is useful for things where it is helpful to be consistent.

ABate: Agree... when talking about platforms and UX they are seperate things. Don't require a particular UX to support a particular platform feature.

MW: What happened in geolocation?

RT: Interesing case. They did lots of privacy and security stuff, but did't put too much UX constraint. And we are still innovating...

MW: You can always ignore the requirements in a spec...

RT: And most did. There was codifying things that make perfect sense, and it was kind of a good level.

ABate: problem in geolocation was that a lot of good somewhat productive discussion about privacy concerns resulted in only a normative requirement to display the origina of requesting page.
... Think we should call out information, but not constrain what you see on the screen.
... Think you should get permission, but explaining the UI requirement becomes a problem.

MC: Worked on that in Opera, and didn't see much evidence that users understand.

<matt> chaals: User interaction with security and privacy are difficult. We should know that we don't know a lot about it.

<matt> chaals: Normative requirements on what to display is a bad idea.

<bryan> s/??/lgombos/

<matt> chaals: Putting information about potential problems is a good idea, we should do more of that.

<adrianba> +1

<nvbalaji> chaals: I am curious, how do you enumerate unknown unknowns :-)

CMN: Can be good to write it all down, can occasionally be good to even specify something, but only if we are *really* sure that the requirement is really what we want.

ABate: Agree that normative requirements even in UI can be good, but they shouldn't be mixed with requirements on the feature itself.

CMN: Agree

Dom: [scribe missed]
... has anyone analysed what we are missing to turn a real web app into a native app. Is there anything missing?
... (making the app feel like a native app to the user)

NM: Return to comment from this morning. There are things that tend to be missing, but think they are in the hands of the OS - is an app there in the same way as a native app.
... users get confused easily because they don't seem to understand the crossover.

DKA: Shouldn't we provide a hint to the UA that something is a web app, so it could be surfaced in the OS mecahnism.
... I run gmail in browser not native app, but that makes it painful to find.

ABate: Developing IE9 we did research in this area. Experimented with various approaches. Pinned site still looks quite like the browser.
... Because we found people recognise things like the browser, and wanted to click a link and make it work like a browser (ctrl-click opens in new tab)...
... We started with something further away from the browser, and came back towards it.

RT: We made stuff you can run chromeless, as a seperate process. When we ran them in the browser that turned out to be pretty bad.
... They behave as native apps, installed, icon on desktop, in list of running apps, etc.

s/installed/installed in the application directory/

JFr: If you see an address bar you think you are online. To communicate that an app is native, it should not have an address bar.
... Should we look like a native one? Web app is a web app. Copying everything is a bad idea, but copying some thing is a good idea.

CMN: Different between hosted web app, and installed app seems clear. What about something in the middle.

CB: Had an installable app that was ad supported. Users are happy to have ads if there is an address bar, but not in an app.

JFr: Actually we are getting used to having ads in installed apps too.

<richt> Shareware had ads...... :)

VG: If you click on something in an app, it opens in browser, and address bar is a feature that enables users to type something else into the address bar.

DKA: THink this issue is a key point for further discussion, so we won't discuss it further.

Agenda bashing

Developer experience

ABate: Not surprising that people talk about developer experience.
... Very hard to write great dev tools. Do we choose between shipping with sucky developer tools or not shipping?

MC: What can we do in specs development to directly involve developer community?
... think it is a scary place to be.

DS: W3C has been looking at that issue. Developer documentation, W3Conf, ...

<adrianba> http://w3conf.org/

<anne> o_O

DS: We're trying to get our documentation stuff together better.

CB: We have some stuff on our site, and are happy to host other vendors' documentation.

Wrap up

DKA: Are there topics we completely missed here?
... things that will come out of this?
... Last thoughts.

Dom: Anne, can you summarise the bugs you logged today?

<blizzard> here's what I'm gonna be working on: https://etherpad.mozilla.org/appcache-notes

BS: Getting notifications through the event-source API will be discussed in web apps.

AvK: Filed bugs: remove requirement for MIME type. Ability to dynamically change manifest URL without breaking things [solutions proposed]
... Tobie filed bug to let appcache work cross-origin.
... Allow apps to use online whenever they can.

CB: Some other stuff to do. Connecting file APIs, etc. There are many things we need to be doing.

<bryan> s/Getting notifications/Getting offline notifications/

CB: Understanding that we are using it for things beyond what we started with for appcache.

<bryan> +1

JS: Worried that if we use an existing mailing list like HTML or Webapps it will be scary. Maybe a Community Group would be good.

<adrianba> +1

AvK: Think it would be useful to have more barcamp-type events between people working on standards, developers, browser vendors.

<bryan> +1

<dom> +1

<matt> +1

<Wonsuk> +1

<dom> StandCamp

<blizzard> haha

DKA: Users view standards space as something that goes one way, and don't think they can influence it.

<darobin> Proposed community group: http://www.w3.org/community/groups/proposed/#fixing-appcache

Wycats: Agree that developers see standards as a black box, and we wanted to evangelise the idea that it isn't impossible to work together.

DKA, mute doug

Hackathon mk X

Wycats: Talked about an implicit inline appcache. More to discuss, but seems there is a way to do that, although won't meet all needs.

<darobin> example of what wycats is talking about: https://github.com/darobin/inception-wiki/blob/master/specathon/example.html

Henri: When doing things for real, you need to be able to do simple basic things. We don't have them now.

Wycats: Think it is cool that we did the hackathon.

DKA: Thanks for coming, hooray, ...

[Thanks to Vodafone for hosting]

<matt> RRSAgent: Draft minutes

- DRAFT -

Offline Web Apps Workshop

05 Nov 2011

Attendees

Contents