17:01:44 RRSAgent has joined #offline 17:01:44 logging to http://www.w3.org/2011/11/05-offline-irc 17:01:51 SungOk_You has joined #offline 17:01:54 filmaj has joined #offline 17:02:06 Present+ Dominique_Hazael-Massieux 17:02:18 Present+ Niklas_Widell 17:02:19 Meeting: Offline Web Apps Workshop 17:02:25 mwbrooks has joined #offline 17:02:26 present+ Magnus_Olsson 17:02:26 Chair: Matt_Womer, Dan_Appelquist 17:02:27 Present+ Jean-Francois_Moy 17:02:30 Present+ Sakari_Poussa 17:02:47 peterlubbers has joined #offline 17:02:58 Present+ Soonho_Lee 17:02:58 Agenda: http://www.w3.org/2011/web-apps-ws/Agenda.html 17:03:07 dcoloma_ has joined #offline 17:03:13 -> http://www.w3.org/2011/web-apps-ws/Papers.html Papers submitted to the workshop 17:03:19 Wonsuk has joined #offline 17:03:21 RRSAgent, make log public 17:03:24 RRSAgent, draft minutes 17:03:24 I have made the request to generate http://www.w3.org/2011/11/05-offline-minutes.html dom 17:03:56 Present+ SungOk_You 17:04:12 Kepeng has joined #offline 17:04:22 shinypb has joined #offline 17:04:24 nvbalaji has joined #offline 17:04:33 Do we have a Twitter hashtag? 17:04:35 Present+ Laszlo_Gombos 17:04:35 Present+ Balaji_NV 17:04:39 Present+ Filip_Maj 17:04:47 mwbrooks, it has been suggested to use #offline as well as tiwtter hashtag 17:04:49 Present+ Wonsuk_Lee 17:05:02 michaeln has joined #offline 17:05:03 dom: makes sense, thanks! 17:05:58 ArtB has joined #offline 17:06:15 JanL has joined #offline 17:06:53 Present+ Ernesto_Jimenez 17:07:20 Present+ Dowan_Kim 17:08:01 dom: yea, #offline is already a popular tag. #offlineweb it is 17:09:15 dom has changed the topic to: /#offlineweb is our twitter hashtag 17:09:21 Present+ Rich_Tibbett 17:09:41 shan has joined #offline 17:10:19 darobin has joined #offline 17:10:45 a12u has joined #offline 17:11:35 Present+ Mark_Christian 17:13:18 Dong-Young_Lee has joined #offline 17:17:28 Present+ Virginie_Galindo 17:18:41 stakagi has joined #offline 17:18:53 shepazu has joined #offline 17:20:52 yosuke has joined #offline 17:22:45 chaals has joined #offline 17:24:12 henri has joined #offline 17:24:56 yes 17:25:03 need developers to speak 17:26:01 Youngsun has joined #offline 17:26:41 anne: did we get any actual developers? 17:26:50 anne: I've interacted with some, and that's part of my feedback! 17:27:02 anne: but I was hoping that some people would show up 17:27:35 blizzard: I see at least two webdevs in the room 17:27:50 yay two! 17:27:56 anne has joined #offline 17:27:59 +1 17:28:03 4% developers 17:28:09 it is conceivable that I may not know everyone :) 17:28:23 indeed, me either 17:28:45 RRSAgent, draft minutes 17:28:45 I have made the request to generate http://www.w3.org/2011/11/05-offline-minutes.html anne 17:28:47 ArtB has joined #offline 17:29:12 We should transform the workshop in a hackaton. It's saturday after all, and we might be enough to have an offline app tonight. 17:29:24 wycats is one 17:29:26 also, I'm not counting people who do standards and develop -- if we add them we get quite a few more 17:29:28 blizzard: ^^ 17:29:30 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 17:29:37 +1 to henri 17:30:04 I have a flight at 6 anyway, so hackathon sounds great :) 17:30:10 (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 in HTML page ) 17:30:19 @dom I like the cheatsheet. 17:30:28 thx :) 17:31:10 yes, the cheatsheet is good stuff 17:32:12 blizzard: I'm a developer 17:32:40 tobie has joined #offline 17:35:32 darobin: six in the morning? that leaves us a couple of hours, let's do it 17:36:11 chaals_ has joined #offline 17:36:23 -> http://www.w3.org/2011/web-apps-ws/papers/Hazael-Massieux-1.html Web Apps as First Class citizens 17:36:35 -> http://www.w3.org/2011/web-apps-ws/papers/Hazael-Massieux-2.html HTTP optimizations for ApplicationCache updates 17:36:49 -> http://www.w3.org/2011/web-apps-ws/papers/Infraware.pdf Sung-Ok, You, Infraware paper 17:37:33 If people are interested, my notes in real time: http://www.evernote.com/shard/s11/sh/88074d12-111c-4e09-b148-5fa21984caf1/2392391d70615322f65b6592881a9c4a 17:38:00 My "quick-fix" proposals: https://gist.github.com/1341809 (I didn't learn about this workshop until after the deadline for papers) 17:38:30 -> http://www.w3.org/2011/web-apps-ws/papers/KDDI.html Offline Web Applications for Disaster Relief 17:39:05 jfmoy: darobin: An offline wiki could be a great app, don't you think? 17:39:11 http://www.w3.org/2011/web-apps-ws/papers/KDDI.html 17:39:13 unfortunately only people who submitted papers are allowed to speak 17:39:22 (now) 17:39:32 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 17:39:40 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 17:39:40 michaeln has joined #offline 17:39:42 well, given the speed we're going over the papers, your turn should come up soon, wycats 17:39:46 to make appcache easier to use 17:39:54 dom: I didn't submit a paper :( 17:39:54 mostly based on what tobie & wycats have said 17:39:55 wycats: we said earlier that we'll open the floor to people who didn't submit papers 17:40:04 darobin: hope so :) 17:40:14 wycats: you'll be able to talk :) 17:40:23 I see no reason why you wouldn't talk 17:40:33 the paper order just gives some order, I think 17:40:33 ernesto_jimenez: awesome :) 17:40:35 RRSAgent, draft minutes 17:40:35 I have made the request to generate http://www.w3.org/2011/11/05-offline-minutes.html dom 17:40:45 anne: +1 on those tickets 17:41:23 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" 17:41:25 JF has joined #offline 17:41:35 oh shit is that a patent 17:41:36 :p 17:42:07 i/Meeting:/ScribeNick: noone/ 17:42:09 RRSAgent, draft minutes 17:42:09 I have made the request to generate http://www.w3.org/2011/11/05-offline-minutes.html dom 17:42:50 q+ to speak about his paper 17:42:51 Please don't modify my note, got a conflict ;) 17:43:28 chaals has left #offline 17:45:55 james knows how to use a mic 17:49:00 michaeln has joined #offline 17:49:34 darobin, that's because he actually didn't need one :) 17:49:44 :) 17:49:45 Present+ Art_Barstow 17:49:55 Present+ Robin_Berjon 17:50:43 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 17:50:53 RRSAgent, draft minutes 17:50:53 I have made the request to generate http://www.w3.org/2011/11/05-offline-minutes.html dom 17:51:32 Zakim has joined #offline 17:51:38 q+ to speak about his paper 17:51:49 darobin: that's nice, isn't it? xD 17:52:01 ernesto_jimenez: yes, it really is :) 17:52:05 q+ wycats to present his views 17:54:40 [one way I thought of working around that was to use data: url as manifests, but that didn't work last time I played with it] 17:54:50 s/around that/around http headers difficulty/ 17:55:08 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 17:55:44 I wonder why we can't support 17:55:49 and 17:56:04 and maybe a tag for resources that are not referenced in the master resource 17:56:07 James has joined #offline 17:56:35 maybe add a to the config.xml? 17:56:36 or 17:57:24 web app, offline app, native app, the differentiating lines between these are starting to blur 17:57:27 why not config.json 17:57:29 BAM 17:57:33 D: 17:57:40 ack charles 17:57:44 ack chaals 17:57:44 chaals, you wanted to speak about his paper 17:57:57 Charles: Widgets and applicationcache are doing similar packaging stuff 17:58:02 ... we need more complex use cases 17:58:10 ... Web apps get deployed in many different way on the Web 17:58:33 dcoloma_ has joined #offline 17:58:36 or even straight onto mobile platforms ie. phonegap 17:58:36 ... via http, via email, via broadcast 17:58:44 yeh 17:58:44 ... Many people have indicated that appcache is broken 17:58:49 ... but widgets work today! 17:59:12 ... we're using them for other things than applications (e.g. opera extensions) 17:59:33 ... while I think that AppCache is a valuable solution, it seems full of problems 18:00:02 Matt_Womer: my concern is that by trying to hit parity with native apps, we start losign some of the advantages of the Web 18:00:07 ... e.g linkability, good UI, etc 18:00:16 q? 18:00:17 q? 18:00:39 Topic: non-paper based presentations 18:00:43 s/valuable solution/valuable part of the platform/ 18:01:00 Wycats: I've looked at AppCache, it has two adoption problems 18:01:07 ... a new mime type: most dev can't change them 18:01:39 ... second problem, appcache makes it very difficult to have an app be just as usual while online, and be well cached while offline 18:01:51 s/we're using them for other things than/we're also happily and successfully using them for other/ 18:01:57 ... I think it's good that appcache is atomic, but there should be another mechanism 18:02:13 wycats: I want to talk about the "use the cache when you're offline" thing 18:02:19 blizzard: cool 18:02:23 I said that the atomic feature of appcache is good 18:02:26 i/Charles: W/ScribeNick: dom/ 18:02:28 wycats: do you think that's something that app cache has a role to play there at all? 18:02:32 s/work today!/work well - although we have stuff that we know we want to add/ 18:02:34 and that programmatic control should probably be a different API as a result 18:02:36 wycats: Feels like a general browser feature 18:02:47 sriramyadavalli has joined #offline 18:02:49 wycats: but we should talk 18:02:51 blizzard: it's essentially the same feature as app-cache *when the user agent is offline* 18:02:54 blizzard: cool 18:02:55 there is a line 18:02:56 look, another telco sending a developer 18:02:59 Jean_Francois: +1 to appcache being a pain to develop with, to debug 18:03:01 we'll end up liking these guys :) 18:03:12 ... I would like to talk also about better integration of Web apps into OS 18:03:35 ... one of my concerns with Web apps is that the user has to launch the browser to start the Web app 18:03:45 ... it sounds like something that would be easy to achieve 18:03:55 [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]. 18:04:11 Michael_R: I wrote PatchTV (?) and Offliner 18:04:21 ... turns a couchdb app into an appcache app 18:04:29 ... also a couchdb and node.js contributor 18:04:38 s/PatchTV/PouchDB/ 18:04:43 matt2 has joined #offline 18:04:49 ... my concern is why appcache is so far away from http caching 18:05:01 https://github.com/mikeal/pouchdb -> PouchDB 18:05:08 hehe pouch 18:05:18 Henri: I suggest we turn this day into a hackathon to detect the actual problems with appcache today 18:05:26 ... e.g. a off-line wiki server to figure out the actual servers 18:05:30 s/servers/problems/ 18:05:49 ... my intuition is that a combination of localstorage and various other javascript api we can make this work 18:06:01 Dan: sounds like an interesting idea 18:06:11 ... we hadn't thought about having an hackathon during the event 18:06:23 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. 18:06:24 ... this could be done in the room at the back of this one 18:06:35 ... my only concern is that we might remove some of the opinions from the discussions 18:06:52 ArtB has joined #offline 18:06:52 ... but if people are interested in that, feel free to do that 18:07:05 msf has joined #offline 18:07:22 howard has joined #offline 18:07:23 @@@_Huawei: an important issue for offline Web apps is how to exchange data between the app and the server 18:07:28 (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...) 18:07:29 Hackathon a great idea; we all need to feel the pain 18:08:08 Doug: talking about manifest, it could be used to apply resources to a page rather than linking them from it 18:08:20 ... I wonder about having unique ids for a given installation of an app 18:08:37 Sicking: I just want to say we need to do this as an iterative process 18:08:53 ... whatever we come up with, it's very important we gather a lot of feedback before we try to nail down anything 18:09:05 ArtB_ has joined #offline 18:09:07 [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] 18:09:08 @@@: I'm one of the co-chairs of the Web & TV IG 18:09:30 ... I'm interested to talk about non-connected TV sets that can receive data from broadcast only 18:09:44 John_Foliot: I'm a Web accessibility guy 18:09:45 [having two apps talk together: intents/activities could at least partly do the trick] 18:10:07 ... I'm interested to reach out to framework dev, etc to make sure that they're accessible to person with disabilities 18:10:09 s/I wonder about having unique ids for a given installation of an app/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/ 18:10:09 adrianba has joined #offline 18:10:26 s/@@@_Huawei/Kepeng_Li 18:10:47 ___@: I'm part of a company that builds a lot of mobile Web apps 18:10:57 ... we're very interested to improvements to manifests 18:11:07 ... it's very hard to test it, and develop with it while updating the content 18:11:26 ... the whole world of caching content still needs to be figured out properly 18:11:31 Present+ Soonbo_Han 18:11:55 RRSAgent, draft minutes 18:11:55 I have made the request to generate http://www.w3.org/2011/11/05-offline-minutes.html dom 18:12:23 s/@@@: I'm one of the/yosuke: I'm one of the/ 18:12:48 present+ Bryan_Sullivan 18:12:52 someone needs to invent a way of tagging objects dynamically 18:13:56 present+ aizu 18:14:23 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? 18:14:55 richt has joined #offline 18:15:51 spoussa has joined #offline 18:23:43 plinss has joined #offline 18:25:58 a12u has joined #offline 18:26:43 a12u has joined #offline 18:30:44 shinypb has joined #offline 18:32:58 jfmoy has joined #offline 18:36:44 nwidell has joined #offline 18:42:02 scribe: Matt 18:42:08 Chris: Use cases and UX are the same to me. 18:42:35 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. 18:43:54 Balaji: Need to discuss convergence, are installed apps required? 18:44:07 James: I'm disappointed that there are only three in the Developer Experience category. Those guys are dying out there. 18:44:58 vgalindo has joined #offline 18:45:08 ??: Life cycle covers DX too. 18:45:29 José: When we are asking for fixing app cache flows, we are talking about the developers. 18:45:44 DKA: Looking at it through the developer lens is slightly different than lifecycle. 18:46:28 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. 18:46:40 DKA: Do you want to start with Protestors, or listing current apps on phone? 18:47:34 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? 18:47:52 DKA: A session in the afternoon where we focus on Use Cases. 18:47:58 chaals: Start with use cases. 18:48:33 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. 18:49:21 José: A top down approach, this is a technical workshop. 18:49:34 José: Could have another session for use cases instad. 18:49:38 s/instad/instead/ 18:49:49 DKA: If people want to split that's fine, but I think a single stream is good. 18:50:14 DKA: Sometimes when you break out you just end up with like minded folks arriving at consensus but not across the breakouts. 18:50:50 DKA: Anything missing on the board? Or not explained? 18:51:29 DKA: We will put this stuff into Google Moderator as a mechanism to prioritize and a tool to organize afternoon discussion. 18:52:05 shinypb has joined #offline 18:56:11 henri has joined #offline 18:58:15 vgalindo has joined #offline 18:58:53 sriramyadavalli has joined #offline 18:59:53 leaving the workshop to go back to europe. ciao. 19:00:08 jfmoy has joined #offline 19:00:54 stakagi has joined #offline 19:04:25 ernesto_jimenez has joined #offline 19:07:18 Hackaton starting 19:07:30 Join the Inception room at the back if you want 19:14:53 shinypb has joined #offline 19:24:05 michaelhanson has joined #offline 19:26:13 tobie has joined #offline 19:28:58 shinypb has joined #offline 19:32:49 mat2 has joined #offline 19:34:23 sriramyadavalli has joined #offline 19:35:00 sicking has joined #offline 19:36:37 plinss has joined #offline 19:37:40 jfmoy has joined #offline 19:39:34 An offline wiki, kind of http://tiddlywiki.com then, but with a server? 19:41:24 ScribeNick: bryan 19:41:29 dowan has joined #offline 19:41:45 matt: using Google Moderator thingy 19:41:52 nvbalaji has joined #offline 19:42:06 http://goo.gl/mod/HHRR 19:42:18 adrianba has joined #offline 19:42:20 ... goto the url 19:42:43 howard has joined #offline 19:42:57 dom: suggestion - vote on topics that will be productive for today 19:43:37 matt: add to the moderator page, only as last resort create a new one 19:45:35 JF has joined #offline 19:45:54 shinypb has joined #offline 19:46:01 marcos has joined #offline 19:46:07 rrsagent, pointer 19:46:07 See http://www.w3.org/2011/11/05-offline-irc#T19-46-07 19:46:20 dan: by 1:15 we will wrapup on use cases 19:46:35 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. 19:46:38 ... if you have ideas on granularity of use cases come up and make your case 19:47:19 dom: not too high use cases, consider what these tools are trying to solve as use cases 19:48:52 dom: use of Webapps when offline, increasing cache performance, making it look like a native app 19:49:07 smus has joined #offline 19:49:11 ... making them distributable 19:49:50 ... beyond HTTP 19:50:49 noah: covered by installed app look and feel? to make them practical for users to install and manage similar to native apps 19:52:04 spoussa has joined #offline 19:52:26 dan: does anyone disagree with "installable" being part of the discussion here 19:52:54 tobie: hostable applications is something important to consider 19:53:38 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 19:53:52 put me in the q: queue! 19:54:10 dan: capturing the action of the user that they are taking possession of something 19:54:12 q? 19:54:21 q+ blizzard 19:54:23 ... what do you install, a link, a package, etc 19:54:41 ack wycats 19:54:41 wycats, you wanted to present his views 19:54:41 Installable could be considered a special case of hostable if there is a local host taking the role of managing the lifecylce 19:54:55 dan: that deserves its own use case. there is an emotional aspect of having something on your computer 19:54:57 q+ 19:55:19 doug: the trust you give to the app when you install it 19:55:28 SungOk_You has joined #offline 19:56:03 and your expectations about what the app can and will do for you and to you 19:56:26 q+ to argue for install 19:56:28 mark: appcache gives developers real control over what is displayed on the page, and would like to focus on that 19:56:47 ack bryan 19:56:53 q? 19:56:58 dcoloma_ has joined #offline 19:57:15 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 19:57:32 zakim, close queue 19:57:32 ok, matt, the speaker queue is closed 19:57:53 dcoloma has joined #offline 19:58:22 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 19:59:02 queue= 19:59:12 ack blizzard 19:59:13 ack noah 19:59:13 noah, you wanted to argue for install 19:59:24 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 20:00:04 ... if you ask the user to manage local stores, the abstraction is wrong. you need to describe the need in terms they understand 20:00:25 ... going that way you can put emphasis on the abstraction of the app, toward what users expect 20:00:31 "Installation of Application being a positive and natural step for users is a myth!!! 20:01:00 User like to conenct with their data, installation maybe be a necessary evil of that process 20:01:08 soonho: we should discuss installable webapps. most user understand the concept that the user is in my device, and should run offline 20:01:12 q- 20:01:22 s /conenct/connect/ 20:01:35 s/soonho/dongyoung/ 20:02:06 (without Google you're also not going to find it...) 20:02:21 dan: (didn;t catch) 20:03:17 "Dockable" applications rather than "Installable" (but might be a matter of definition of course) 20:04:11 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. 20:04:45 shinypb has joined #offline 20:05:25 balaji: +1 to noah's comment. we can build a better security framework around installation. 20:06:04 dan: that's an extra use case - maybe related to making a webapp look like a native app. linking permissions to an installation step 20:06:49 network resilient Web apps? 20:06:51 s/balaji/nvbalaji/g 20:07:36 dom: needs more buzzword 20:08:08 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. 20:08:21 +1 to chaals 20:08:27 kihong has joined #offline 20:08:28 anne, cloud-based strategically network -resilient Web apps? 20:08:31 why install f not needed 20:08:37 o_O 20:09:58 adrianba has left #offline 20:11:04 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. 20:11:28 s/those apps./those apps, and it should be the same experience/ 20:12:28 s/same experience/same experience. And don't forget that the state of the art in this area is still pretty simple and not very good/ 20:12:34 dan: we have to be able to articulate the offline vs installable webapps as different use cases 20:13:06 chris: re security and installation - don't want to talk about it here. we will not solve that here 20:14:03 "install" for the web seems more about granting rights than caching for offline use 20:14:23 dan: getting to consensus on security and permissions etc as a discussion for today 20:14:31 +1 to michaeln 20:15:04 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 20:15:40 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? 20:16:20 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 20:17:27 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? 20:18:00 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 20:18:10 dom: web intents? 20:18:15 chaals: maybe 20:18:24 bryan: the one API to rule them all... 20:18:46 11 is web intents? 20:19:01 anne: can you grant rights w/o "installing"? 20:19:16 s/maybe/maybe, but "web intents" isn't a *use case*, it is a "potential solution" 20:20:08 dan: a lot of the topics hitting here are related to lifecycle, and that is our top topic on moderator - wait - check - fixing appcache flaws is #1 20:20:08 adrianba has joined #offline 20:20:49 chaals: would like rather than fixing it, think about what it can/cant do, note that some will fix it, and this would hijack the discussion 20:21:07 dan: it might be useful to spinoff into a breakout 20:21:24 s/and this would/and not go so far into it that it would/ 20:21:29 dom++ 20:21:44 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 20:21:53 dan: talking about adding features? 20:22:28 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 20:22:52 dan: one of the things is how appcache is not possible for some developers to use 20:23:40 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 20:23:52 long term is one and a half year? sweet 20:23:57 ... crucial to fix it as a short-term strategy 20:25:04 https://etherpad.mozilla.org/appcache-notes 20:25:11 that's my full list of notes about app cache 20:25:23 stuff that needs to be fixed, added, broken, experience changes and posts about iut 20:25:26 it 20:25:32 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 20:25:49 (very firefox-focused, sorry) 20:25:54 RRSAgent, draft minutes 20:25:54 I have made the request to generate http://www.w3.org/2011/11/05-offline-minutes.html dom 20:26:21 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 20:26:37 anne: are you talking about the difference between install and opportunistic caching? 20:26:44 anne: they are different! 20:26:46 anne: (in the doc) 20:26:54 err, etherpad 20:27:28 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 20:27:53 adrian: would like to hear about the problems with appcache 20:28:04 What exactly do we want to achieve in this room? 20:28:08 blizzard: yes 20:28:31 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 20:28:39 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 20:28:56 blizzard: so a UA can't e.g. list pages using manifest= on a special page when the user opens the browser when offline 20:29:00 +1 chaals 20:29:20 dan: would like to constrain the discussion to what it is supposed to do, rather than things we wish it to do 20:29:24 anne: I'm not entirely sure what you mean, should discuss with voices 20:29:30 It's important that we do not disappoint Appcache folks 20:30:17 dan: the point is what is broken is part of the bigger discussion 20:30:23 tobie has joined #offline 20:30:23 http://www.stevesouders.com/blog/2011/10/03/improving-app-cache/ 20:30:26 that's the link 20:30:51 also the list of urls in the etherpad 20:31:20 steve: it would be good to come to consensus on these issues 20:31:36 tobie: recommend to read the points in the paper about appcache flaws 20:31:40 shinypb has joined #offline 20:31:55 -> http://www.w3.org/2011/web-apps-ws/papers/Facebook.html Tobie's paper 20:32:02 noah: do people feel we have enough clarity on the requirements of the workshop? 20:32:41 dan: we need to consider the use cases in addition to the pain that developers have with appcache 20:33:03 s/dan: we/dandruta: we/ 20:33:09 I haven't read it 20:33:11 :( 20:33:32 nwidell has joined #offline 20:33:33 dan: suggest we need to start with the issues with appcache 20:33:35 chaals+ 20:33:49 tobie: presents his paper 20:34:09 ... the point of appcache is to enable app use when offline 20:34:28 ... but a number of very small flaws 20:34:53 ... appcache is designed to allow offline web apps that can access online resources when connected 20:35:29 [+1 to "you need to be able to update the manifest easily"] 20:35:33 ... 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 20:35:46 ... in mvc cases where the markup is chrome, this makes sensew 20:35:55 ... but it should not be the only option 20:36:28 ... the ability to ask for caching of all manifest pages 20:37:03 ... 2nd problem is the way that the app updates itself - the manifest file being the key breaks fingerprinting, and results in cache-busting 20:37:25 [+1 to "Simplify the process of adding manifest/config/etc metadata of different types *including* manifest"] 20:38:21 ... the manifest being identified by URL, prevents developers from busting the cache 20:38:46 ... if you want resources to be updated, you have to change the manifest (e.g. comments) 20:38:49 we could keep the url as the identifier, but add a manifestVersion attribute or something? 20:39:28 ... changing the manifest file name 20:39:43 ... but not nuke the cached contents 20:39:56 chaals: you may want to nuke one file, but keep the others 20:40:10 so you want something like: 20:40:20 20:40:47 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 20:40:53 [+1 to "you want to be able to get stuff across different networks"] 20:41:00 anne, that'd be another approach to it indeed 20:41:25 noah: I want to persist content, and when I change the manifest I want to update only the changed content 20:42:04 tobie: looking at the use cases, there are things that can be improved 20:42:20 I'm kinda confused 20:42:21 noah: minimal disruption to what is deployed could be a 3rd requiremet 20:42:35 [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] 20:42:43 smus has joined #offline 20:42:48 tobie: 3rd requirement is to put appcache on CDNs 20:42:51 sigh 20:43:20 RRSAgent, draft minutes 20:43:20 I have made the request to generate http://www.w3.org/2011/11/05-offline-minutes.html dom 20:43:38 ... to recap, the autocaching of master entries can be opt-in - i.e. an online app is online, and not the opposite 20:43:44 [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?] 20:43:51 ... 2nd addressing the cache busting issues 20:44:07 [I'm not sure if Tobie's fixes include "get it from online unless you're offline"] 20:44:13 ... 3rd addressing performance issues e.g. via CDNs 20:44:44 I still don't understand 2. 20:44:47 I will need to figure that out 20:44:48 tobie has joined #offline 20:44:52 [Not sure if CORS can be tied to it.] 20:45:01 tobie: you should find me later to explain the cache busting problems to me 20:45:05 dan: is there anything to disagree with or not covered 20:45:19 [[1. Flip model to allow online applications to be online. 2. Fix fingerprinting/cache busting 3. make it work with CDNs]] 20:45:35 [2. Enabling live incremental changes to the manifest] 20:46:32 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 20:46:44 tobie: i'd like to understand your cache busting problems better too 20:47:09 peter: going over quota 20:47:28 chris: thats different, some consistency would be good 20:47:41 dan: what is you run out of space? 20:47:51 q+ 20:47:59 Chris: Only Opera and Safari ask to store and have limits 20:48:10 matt: opera and firefox 20:48:15 [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] 20:48:18 s/Safari/Firefox/ 20:48:43 boris: anyone thought about the game use cases, e.g. instant on - appcache loads all at one or not at all. 20:49:10 ... storing large amounts of assets, you dont know how far along you are 20:49:29 [+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] 20:49:37 michaeln: I'm happy to explain it in person. 20:49:58 [+1 to IndexDB with Large File Support] 20:50:32 [-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] 20:50:33 michaeln: it's very difficult to explain without going through the whole process of how AppCache works. 20:50:37 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 20:50:43 nwidell has joined #offline 20:50:46 [+1 for access to the file system] 20:50:49 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. 20:50:58 file api and file system api are different things. 20:51:01 shinypb has joined #offline 20:51:14 jose: my basic use case is use my web server when online and use appache to get my content when not online 20:51:20 file api lets you get to resources, but those resources could be in a local file or indexeddb or websql or whatever 20:51:28 or even in the app cache! 20:51:40 bryan: access to the filesystem is essential for offline apps to get beyond the browser limitations 20:52:17 @@@: ability to store more content than browsers will allow - what is the direction 20:52:58 s/@@@/Jean-Francois?/ 20:53:50 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. 20:54:33 tobie has joined #offline 20:55:02 s/Jean-Francois?/Jean-Francois/ 20:55:59 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 20:56:01 +1 appcache should focus on bootstrapping more than storing dynamic media assets... filesystem and indexdb can work for that 20:57:26 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. 20:57:42 +1 chaals for query on cache space availability 20:58:13 dan: additional points? 20:58:16 s/. the other/, rather than some more complex technology that works better but is harder for developers. 20:58:32 blizzard: I can explain the case for #2 20:58:34 jose: recommendation from the workshop to revisit the appcache design? 20:59:02 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 20:59:08 dan: we will identify the recommendations for the current appcache feature 20:59:24 blizzard: but then sometimes you do need to update it but you can't because it is "permanently" cached 20:59:42 blizzard: there's a technique called "fingerprinting" in which you basically change the URL when you change the resource 20:59:57 blizzard: but that technique cannot be used for manifests because it's identifier is the URL 21:00:20 dan: adding large assets to the use cases 21:00:23 blizzard: and if you use a new URL you have effectively a whole new thing and the browser will not reuse existing cache hosts 21:00:46 bryan: we need to keep mind that appcache is not usable for files that are created / updated as part of the app 21:01:00 anne: I'm a little surprised that it doesn't keep the resources and check them 21:01:02 anne: ok 21:01:18 any additional info on large file support for indexed db beyond http://goo.gl/XVXsp? 21:01:21 michael: programmable cache can be looked at as a way to handle dynamic cached content 21:01:30 http://www.w3.org/TR/DataCache/ 21:01:34 smus: ask sicking 21:02:01 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 21:02:11 [+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] 21:02:11 it, it* 21:02:12 smus: https://bugzilla.mozilla.org/show_bug.cgi?id=661877 21:02:16 anne: ok, got it 21:02:18 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? 21:02:21 -> http://www.w3.org/TR/DataCache/ Data Cache 21:02:25 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 21:02:31 anne: I didnt' realize that changing the url of the manifest file would blow away all the resources 21:02:48 blizzard: great, looks like this is cleared already. 21:02:49 anne: sounds like it just needs to be more opportunistic 21:03:08 jonas: agreed that there were differences, but they are some things that could be added to appcache to bring them closer together 21:03:21 tobie: thx 21:03:53 jonas: we can have an extra section in the manifest, e.g. deliver requests to a javascript file 21:04:36 blizzard: I guess you could instead use the manifest URLs as identifiers or some such 21:04:46 blizzard: instead of requiring more syntax 21:04:54 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. 21:05:00 s/manifest URLs/master entry URLs/ 21:05:18 anne: *nod* 21:05:37 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 21:05:56 chris: an installable app should be coherent, and opportunistic cache can be flexible 21:06:28 +1 jonas "deliver request to script" handwave 21:07:44 RRSAgent, draft minutes 21:07:44 I have made the request to generate http://www.w3.org/2011/11/05-offline-minutes.html dom 21:08:11 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. 21:11:54 kyongsok has joined #offline 21:12:17 shinypb has joined #offline 21:14:19 plinss has joined #offline 21:31:00 jfmoy has joined #offline 21:31:05 spoussa has joined #offline 21:31:13 michaeln has joined #offline 21:31:49 smus has joined #offline 21:31:54 richt has joined #offline 21:31:54 Topic: convergence 21:32:35 tobie has joined #offline 21:32:54 matt: we are all appcache-heavies in this room... but now something about widgets from marcos 21:33:33 marcos: widgets are relevant, as quite a few are working on widget engines. widgets are primarily a packaing format and API for the manifest. 21:34:07 ... its pretty simple, e.g. by Opera and for extensions e.g. in PhoneGap 21:34:12 sicking has joined #offline 21:35:18 ... 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 21:35:21 ernesto_jimenez_ has joined #offline 21:36:25 ... re appcache, widgets and appcache serve different purposes, also other approaches such as APK-based approaches that use WebView 21:37:36 ... 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 21:38:24 ... I would be interested in talking about these issues e.g. at the next break 21:39:27 +1 Marcos for common packaging manifest 21:40:03 ... 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 21:40:33 tobie: blizzard: I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=14704 21:41:08 anne: ty 21:41:33 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) 21:42:23 ... 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? 21:42:39 +1 dan for talking about 21:42:39 matt: group hug for dan 21:44:05 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? 21:45:13 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? 21:45:49 dan: maybe one thing is to consider stuff in the widgets specs that are extraneous, something that can be pared down 21:46:20 chaals: config.xml packaging is one, json as an alternative 21:47:30 ... a nice features is localization, built-in to the packaging, enabling self-localizing multi-lingual applications 21:47:55 ... a missing feature is something appcache provides, the ability to run online and then move offline 21:48:11 ... widgets cant constrain where your assets are kept 21:48:34 sicking: http://colinm.org/language_checklist.html 21:48:48 ... 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 21:49:26 ... there may be another missing piece re how you repackage into a different directory structure 21:49:37 ... also inter-widget messaging is a limitation 21:50:10 ... but as before they are not hell on earth to program they are nice, and something to consider as part of a better solution 21:50:46 dom: one thing to focus on, is anyone interested in convergence by implementers in this space 21:51:11 vidhya: is there a view in this room that we need a standard container? 21:51:26 matt: do you think converging these things is a good idea? 21:52:45 ... anyone against looking for a convergence where you can use something that grew out of widget and appcache in the same solution? 21:53:19 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? 21:54:19 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 21:54:46 ... one thing we both agree, both enable offline web apps - do we need two technologies 21:55:07 marcos: I want a calculator I can build install and run on my computer and be done 21:56:16 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 21:56:51 noah: use cases: as a traditional web app, lots of uris for resources that come down and may be installed for offline use 21:57:16 ... next is the marketplaces, using this as an approach to address the fragmentation 21:57:38 ... another us putting an app on a usb key and installing it without dependence upon uris 21:57:48 +1 tobie for common manifest 21:58:04 ... how do I put those together into a common framework 21:59:06 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 22:01:26 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. 22:01:53 marcos has joined #offline 22:03:17 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 22:03:57 chaals: we could in response kill off one, or converge the two 22:05:01 sriramyadavalli has joined #offline 22:05:31 ... 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 22:05:43 ... that would be more constructive 22:06:18 ... otherwise we can fight over the two technology stacks, and that will be quite expensive 22:06:46 dan: its worse, as a developer I have to do multiple things beyond all that 22:07:09 tobie: nitobi has good experience with widgets, comments? 22:08:26 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 22:09:09 phil: phonegap's use is a superset - a different way to ask this is what is the superset 22:09:38 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. 22:09:56 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. 22:10:22 [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] 22:10:37 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. 22:11:10 both technologies describe things about apps; define metadata 22:11:15 in my opinion merging them makes a lot of sense 22:11:24 jose : agree with bryan, confusion will reign if we dont pursue convergence 22:12:06 dan: can someone from W3C talk about the state of widgets and what we see is next 22:12:39 doug: its drawing to a close .... 22:12:51 marcos: as editor, its's done 22:14:04 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 22:14:51 dan: is it possible for bringing appcache into webapps and consider it with widgets as the next standard basis 22:15:32 howard has left #offline 22:15:44 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 22:16:15 Wiki for HTML.next -> http://www.w3.org/wiki/HTML/next 22:17:09 boris: 2 points - the two models are quite different. for widgets you don't have an initial loading of the cache for example 22:17:43 smus has joined #offline 22:17:48 dan: should appcache have the ability to allow the user to install the app on the device? 22:18:12 noah: you need to ask devs if they want that, and does appcache give you what you want for that 22:18:41 chris: that's not appcache driven its ua driven 22:18:56 noah: do you have a link about the iphone behavior you describe? 22:19:06 dan: we heard about adding a hint indicating that this is an installable app 22:19:29 dom: there is an html5 "application name" meta tag 22:20:26 ... a point-by-point comparison can be done 22:21:42 @@@: we already see different approaches, and a common approach would be good - fragmentation is bad as its good for developers to have one way 22:21:50 s/@@@/jean-francois/ 22:22:15 shinypb has joined #offline 22:22:19 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. 22:22:58 bryan: AppCache is about optimizing caching. Some implementations make use of this to make things installable. 22:23:01 bryan: It doesn't tell you everything you need, like what icon. 22:23:03 22:23:21 bryan: Having these things converge and yet remain with different purposes doesn't make sense for developers. 22:24:00 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 22:24:43 tobie: developers want something that is not bad to use, and is one approach - we should avoid making developers unhappy 22:25:19 bryan: I like how you clean-up my language. ty. 22:26:04 chaals: poll on continuing discussion or splitting off and addressing convergence 22:26:59 Dan just nailed it 22:27:06 [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'] 22:27:32 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 22:29:42 topic: lifecycle 22:35:36 a12u has joined #offline 22:40:15 a12u has joined #offline 22:51:27 shinypb has joined #offline 22:52:40 scribe: chaals 22:53:15 s/lifecycle/hackathon update/ 22:53:50 wycats: Ended up doing typical JS stuff. First hour was pretty instructive. 22:54:10 1. nobody had a server, so building an app like an offline wiki page was tricky. 22:54:20 ... couldn't serve a manifest file. 22:54:26 magnus has joined #offline 22:54:45 ... Had issues where managing the caching of the cache manifest was unclear. 22:54:57 ... Couldn't pretend to be in online mode. 22:55:14 sounds like typical issues I run into as well... 22:55:18 ... Talked about how we'd like to be able to add a URL to the cache. 22:55:42 ... I wanted to be able to bootstrap a cache manifest, and we kept wanting that. 22:55:59 RB: Would be simple to have eg a cache attribute to get stuff cached. 22:56:00 +1 to bootstraping the cache from local files 22:56:20 DKA: Still working, towards a demo? 22:56:43 RB: No, going to maybe propose the cache attribute. Make a specathon. 22:56:48 anne has joined #offline 22:57:02 Topic: Lifecycle management. 22:57:09 plinss has joined #offline 22:57:29 Does Lfe cycle management make sense given that we do not have consensus on convergence 22:57:39 shinypb has joined #offline 22:57:48 DKA: Think that relates to user experience... 22:58:34 [don't think we need convergence - life cycle happens in each world already. Might no longer be the top topic though] 22:58:54 JL: We used widgets in our life cycle, not sure what W3C's role would be there. 22:59:23 ... in OIPF we described how to install, update, remove widgets and get a list of the widgets that are installed. 22:59:27 But we know how the life cycle, if applicable, happens in each world 23:00:03 Soonho has joined #offline 23:00:15 richt has joined #offline 23:00:28 ... Have 3 use cases - coming from a trusted source, coming from an identified service provider, coming from "anywhere else" with no direct trust. 23:00:56 ... Can we get something from W3C for this? 23:01:29 NVB: We know how the lifecycle works in each world. If we're not looking for convergence, what's the question? 23:01:40 MC: What is the use case - what do you want from the life cycle? 23:02:09 ??: Problems discussed are related to stages in a life cycle of an application - online? cacheable? etc. 23:02:25 ... we may not have to look at this as a whole, but look at each piece. 23:02:26 shinypb has joined #offline 23:02:33 ... Life cycle is an important aspect. 23:02:56 http://www.oipf.tv/docs/Release2/V2.1/OIPF-T1-R2-Specification-Volume-5-Declarative-Application-Environment-v2_1-2011-06-21.pdf 23:03:14 this is the link to what I referred to as OIPF widget or application lifecycle 23:03:15 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? 23:03:19 refer to section 5 23:03:28 DKA: Isn't that an implementation detail? 23:03:32 MC: Exactly. 23:04:29 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 23:04:30 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. 23:04:35 magnus has joined #offline 23:05:40 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. 23:05:55 ... e.g. what is the right technology for games to load up lots of assets. 23:06:08 ... is there a need for a best practices document around the use of these technologies? 23:06:46 ... MWBP didn't go into great detail about how to do it... 23:07:02 Dom: Think we need to fix them before trying to explain them. 23:07:42 ... Doesn't help to spend effort on describing how to use something that is broken. 23:07:54 CMN: Short answer: No. 23:08:15 MW: Why wouldn't we want to write up best practices for using what we have? 23:09:00 chaals: We could have an effort for lots of things, but W3C should probably fix app cache rather than write about it. 23:09:10 michaeln has joined #offline 23:09:40 Bryan: Think other technologies related (local storage, indexedDB etc) are part of the problems we have. 23:09:50 ... these are all topics for offline web apps. 23:10:35 NM: I thought this was about describing what the user sees and what the user expects. 23:11:08 ... don't think appcache is speaking to the user yet. 23:11:19 AvK: It is transparent to the user. Think that is better 23:11:53 NM: Maybe. I don't think it gets up to the level where we can do this yet, so that's an answer. 23:12:01 Topic: User experience 23:12:05 ernesto_jimenez_ has joined #offline 23:12:32 MW: Is there anything we can do to improve the user experience, how apps interact with each other, how do we improve performance? 23:12:58 DKA: Also talked about the question about how to get into priveliged resources? 23:13:31 chaals: I fundamentally disagree with the idea that installed apps are installed and the user is done. 23:14:09 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?" 23:14:22 chaals: OTOH, if it's "take money off my phone", you probably want to say "please ask before you take money away" instead. 23:14:57 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. 23:15:06 chaals: It should be the same way, off and on. 23:15:13 MW: There is a case that installed apps implicitly have permission to do stuff. 23:15:27 s/MW: There is a case that installed apps implicitly have permission to do stuff.// 23:15:45 i/chaals: I funda/MW: There is a case that installed apps implicitly have permission to do stuff./ 23:16:08 ABate: Don't think anyone says installing an app should give you all possible permissions, and if they are they should stop. 23:16:18 ... but there are things you want to allow, having installed an app. 23:16:47 ... e.g. same origin policy for an app that connects you to facebook and vkontakte and mixit. 23:17:25 ... In an open web app, we don't want to change same origin restriction (without CORS), byt maybe in installed app it is OK 23:18:06 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. 23:18:25 ... Think the model we have at the moment in web apps works out. 23:18:54 RT: Agree. User experience is a broad area and what you do depends on context. 23:19:24 ... 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. 23:20:00 ?? 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. 23:20:24 DKA: If you need to prompt a user for something, there is no specified way to prompt. 23:20:42 CB: [scribe missed it] 23:21:09 ... educating users to understand the lock icon was hard, and slow, and expensive. 23:21:40 ... Green bar for EV certs is widespread. Having understanding and working together is useful for things where it is helpful to be consistent. 23:22:10 ABate: Agree... when talking about platforms and UX they are seperate things. Don't require a particular UX to support a particular platform feature. 23:22:30 MW: What happened in geolocation? 23:22:41 Zakim has left #offline 23:22:55 RT: Interesing case. They did lots of privacy and security stuff, but did't put too much UX constraint. And we are still innovating... 23:23:11 MW: You can always ignore the requirements in a spec... 23:23:29 RT: And most did. There was codifying things that make perfect sense, and it was kind of a good level. 23:24:21 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. 23:24:40 ... Think we should call out information, but not constrain what you see on the screen. 23:25:02 ... Think you should get permission, but explaining the UI requirement becomes a problem. 23:25:07 q+ 23:25:30 MC: Worked on that in Opera, and didn't see much evidence that users understand. 23:26:08 chaals: User interaction with security and privacy are difficult. We should know that we don't know a lot about it. 23:26:21 chaals: Normative requirements on what to display is a bad idea. 23:26:25 s/??/lgombos/ 23:26:31 chaals: Putting information about potential problems is a good idea, we should do more of that. 23:26:35 +1 23:27:11 q? 23:27:17 chaals: I am curious, how do you enumerate unknown unknowns :-) 23:28:44 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. 23:29:21 ABate: Agree that normative requirements even in UI can be good, but they shouldn't be mixed with requirements on the feature itself. 23:29:25 CMN: Agree 23:30:00 Dom: [scribe missed] 23:30:23 ... has anyone analysed what we are missing to turn a real web app into a native app. Is there anything missing? 23:30:45 ... (making the app feel like a native app to the user) 23:31:43 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. 23:32:00 ... users get confused easily because they don't seem to understand the crossover. 23:32:51 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. 23:33:03 ... I run gmail in browser not native app, but that makes it painful to find. 23:33:37 ABate: Developing IE9 we did research in this area. Experimented with various approaches. Pinned site still looks quite like the browser. 23:34:14 ... 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)... 23:34:27 ... We started with something further away from the browser, and came back towards it. 23:34:52 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. 23:35:08 ... They behave as native apps, installed, icon on desktop, in list of running apps, etc. 23:35:29 s/installed/installed in the application directory/ 23:35:30 ernesto_jimenez_ has joined #offline 23:36:01 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. 23:36:39 ... 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. 23:37:26 CMN: Different between hosted web app, and installed app seems clear. What about something in the middle. 23:38:00 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. 23:38:14 JFr: Actually we are getting used to having ads in installed apps too. 23:38:17 Shareware had ads...... :) 23:39:14 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. 23:39:38 DKA: THink this issue is a key point for further discussion, so we won't discuss it further. 23:40:01 Topic: Agenda bashing 23:40:47 Topic: Developer experience 23:41:04 ABate: Not surprising that people talk about developer experience. 23:41:31 ... Very hard to write great dev tools. Do we choose between shipping with sucky developer tools or not shipping? 23:41:49 MC: What can we do in specs development to directly involve developer community? 23:41:56 ... think it is a scary place to be. 23:42:26 DS: W3C has been looking at that issue. Developer documentation, W3Conf, ... 23:42:28 http://w3conf.org/ 23:43:28 o_O 23:43:34 ... We're trying to get our documentation stuff together better. 23:44:39 CB: We have some stuff on our site, and are happy to host other vendors' documentation. 23:45:06 shinypb has joined #offline 23:45:50 Topic: Wrap up 23:46:11 DKA: Are there topics we completely missed here? 23:46:21 ... things that will come out of this? 23:46:26 ... Last thoughts. 23:46:46 Dom: Anne, can you summarise the bugs you logged today? 23:47:12 here's what I'm gonna be working on: https://etherpad.mozilla.org/appcache-notes 23:47:36 BS: Getting notifications through the event-source API will be discussed in web apps. 23:48:54 AvK: Filed bugs: remove requirement for MIME type. Ability to dynamically change manifest URL without breaking things [solutions proposed] 23:49:07 ... Tobie filed bug to let appcache work cross-origin. 23:49:22 ... Allow apps to use online whenever they can. 23:50:02 CB: Some other stuff to do. Connecting file APIs, etc. There are many things we need to be doing. 23:50:26 s/Getting notifications/Getting offline notifications/ 23:50:27 ... Understanding that we are using it for things beyond what we started with for appcache. 23:51:15 +1 23:51:24 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. 23:51:32 +1 23:52:14 AvK: Think it would be useful to have more barcamp-type events between people working on standards, developers, browser vendors. 23:52:19 +1 23:52:49 +1 23:53:00 +1 23:53:12 +1 23:53:18 StandCamp 23:53:19 haha 23:53:37 DKA: Users view standards space as something that goes one way, and don't think they can influence it. 23:53:59 Proposed community group: http://www.w3.org/community/groups/proposed/#fixing-appcache 23:54:07 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. 23:54:30 DKA, mute doug 23:54:53 Topic: Hackathon mk X 23:55:21 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. 23:55:25 example of what wycats is talking about: https://github.com/darobin/inception-wiki/blob/master/specathon/example.html 23:56:07 Henri: When doing things for real, you need to be able to do simple basic things. We don't have them now. 23:56:33 Wycats: Think it is cool that we did the hackathon. 23:57:03 DKA: Thanks for coming, hooray, ... 23:57:36 [Thanks to Vodafone for hosting] 23:59:30 jfmoy has joined #offline 00:45:38 michaeln has joined #offline 00:46:24 shinypb has joined #offline 00:50:34 filmaj has joined #offline 01:22:26 filmaj has left #offline 02:17:55 RRSAgent: Draft minutes 02:17:55 I have made the request to generate http://www.w3.org/2011/11/05-offline-minutes.html matt 02:17:57 RRSAgent, draft minutes 02:17:57 I have made the request to generate http://www.w3.org/2011/11/05-offline-minutes.html matt 02:44:01 sicking has joined #offline 03:22:20 noah has joined #offline 03:57:02 stakagi has joined #offline 04:50:32 sicking has joined #offline 06:04:12 michaeln has joined #offline 06:25:56 shepazu has joined #offline 06:53:20 lgombos has joined #offline 07:03:35 lgombos_ has joined #offline