IRC log of offline on 2011-11-05

Timestamps are in UTC.

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