12:56:57 RRSAgent has joined #sysapps 12:56:57 logging to http://www.w3.org/2013/08/27-sysapps-irc 12:57:05 trackbot, start meeting 12:57:05 Sorry, but no Tracker is associated with this channel. 12:57:23 Zakim, this is SysApps 12:57:23 ok, timeless; that matches UW_SYSAPPS()8:00AM 12:57:38 Zakim, who is here? 12:57:38 On the phone I see [Mozilla] 12:57:39 On IRC I see RRSAgent, Zakim, trackbot, scheib, richt, anssik, timeless, Josh_Soref, schuki, mounir 12:58:16 trackbot, start meeting 12:58:16 Sorry, but no Tracker is associated with this channel. 12:58:42 trackbot, status 12:58:42 Sorry, but no Tracker is associated with this channel. 13:00:02 RRSAgent, make logs world 13:00:14 Zakim, code 13:00:14 I don't understand 'code', timeless 13:00:31 Zakim, what is the code? 13:00:31 the conference code is 79727 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), timeless 13:01:28 gmandyam has joined #sysapps 13:01:34 Meeting: SysApps Face-to-Face #2 13:02:09 Chair: mounir 13:02:12 Scribe: Josh_Soref 13:02:15 ScribeNick: timeless 13:03:13 dsr has joined #sysapps 13:03:43 Zakim, [Mozilla] contains dsr, anssik, marcos, mounir, spoussa, kwallis, zoltan 13:03:43 +dsr, anssik, marcos, mounir, spoussa, kwallis, zoltan; got it 13:05:20 opoto has joined #sysapps 13:05:28 spoussa has joined #sysapps 13:06:28 JonathanJ1 has joined #sysapps 13:06:50 Present+ Anssi_Kostiainen 13:07:19 Present+ Jonghong_Jeon 13:07:30 lgombos has joined #sysapps 13:09:28 s/Chair: mounir/Chair: mounir, wonsuk/ 13:09:56 Zakim, [Mozilla] also has wonsuk 13:09:56 +wonsuk; got it 13:10:05 RRSAgent, draft minutes 13:10:05 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 13:10:22 RRSAgent, make logs world 13:10:23 RRSAgent, draft minutes 13:10:23 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 13:10:33 s/Sorry, but no Tracker is associated with this channel.// 13:10:34 s/Sorry, but no Tracker is associated with this channel.// 13:10:36 s/Sorry, but no Tracker is associated with this channel.// 13:10:38 RRSAgent, draft minutes 13:10:38 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 13:10:51 s/trackbot, start meeting// 13:10:53 s/trackbot, start meeting// 13:10:59 s/trackbot, status// 13:11:01 RRSAgent, draft minutes 13:11:01 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 13:11:44 zkis has joined #sysapps 13:12:01 show has joined #sysapps 13:12:19 lgombos has joined #sysapps 13:12:21 Dong-Young has joined #sysapps 13:14:09 topic: Agenda 13:14:13 mounir: good morning everyone 13:14:19 ... the first thing we should do is an Agenda Review 13:14:29 jungkees has joined #sysapps 13:14:38 ... i know people have things they might want to change this 13:14:45 Present+ Jungkee_Song 13:15:38 Present +Sakari_Poussa 13:15:40 [ mounir goes to find Microphones ] 13:15:46 Zakim, who is here 13:15:46 timeless, you need to end that query with '?' 13:15:49 Zakim, who is here? 13:15:49 On the phone I see [Mozilla] 13:15:50 [Mozilla] has dsr, anssik, marcos, mounir, spoussa, kwallis, zoltan, wonsuk 13:15:50 On IRC I see jungkees, Dong-Young, lgombos, show, zkis, spoussa, opoto, dsr, gmandyam, RRSAgent, Zakim, trackbot, scheib, richt, anssik, timeless, Josh_Soref, schuki, mounir 13:15:51 JonathanJ1 has joined #sysapps 13:15:59 Present+ Laszlo_Gombos 13:16:03 Claes has joined #sysapps 13:16:03 RRSAgent, draft minutes 13:16:03 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 13:16:09 Present+ Olivier_Potonniee 13:16:17 wonsuk_ has joined #sysapps 13:16:28 Present+ Claes_Nilsson 13:17:16 Present+ Zoltan_Kis 13:17:16 dsuwirya has joined #sysapps 13:17:16 thinker has joined #sysapps 13:17:26 Daniel has joined #sysapps 13:17:29 Present+ Dave_Raggett 13:17:37 Present+ Mounir_Lamouri 13:17:45 http://www.w3.org/wiki/System_Applications:_2nd_F2F_Meeting_Agenda 13:17:47 Bo_CHEN has joined #sysapps 13:17:48 hsinyi has joined #sysapps 13:17:53 Present+ Wonsuk_Lee 13:18:03 [ Microphones arrive ] 13:18:05 marcosc has joined #sysapps 13:18:12 zakim, who is here? 13:18:12 On the phone I see [Mozilla] 13:18:13 [Mozilla] has dsr, anssik, marcos, mounir, spoussa, kwallis, zoltan, wonsuk 13:18:13 On IRC I see marcosc, hsinyi, Bo_CHEN, Daniel, thinker, dsuwirya, wonsuk_, Claes, JonathanJ1, jungkees, Dong-Young, lgombos, show, zkis, spoussa, opoto, dsr, gmandyam, RRSAgent, 13:18:13 ... Zakim, trackbot, scheib, richt, anssik, timeless, Josh_Soref 13:18:14 mounir: can you hear me better? 13:18:24 Present+ Bo_CHEN 13:18:32 ... comments on the agenda? 13:18:34 Present+ KuiFeng_Lee 13:18:38 RRSAgent, draft minutes? 13:18:38 I'm logging. Sorry, nothing found for 'draft minutes' 13:18:42 RRSAgent, draft minutes 13:18:42 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 13:18:58 zkis: are we fine with the agenda? 13:19:11 anssik: about Task Forces 13:19:15 kjwallis has joined #sysapps 13:19:20 ... do we want to fill in the blanks tomorrow, or do people have proposals? 13:19:56 zkis: Messaging, Telephony, Contacts could be one group of people 13:20:04 mounir: if people want to do that, we could do that 13:20:04 genelian has joined #sysapps 13:20:14 ... but we should do that tomorrow before splitting into groups 13:20:19 ... Anything else for the Agenda? 13:20:39 Josh_Soref: I'm Josh Soref, BlackBerry, i'll be your scribe today 13:20:42 kenneth_ has joined #sysapps 13:21:02 marcosc: Marcos Caceres, Mozilla, I edit a few specs including App URI and helping zkis with telephony 13:21:12 spoussa: Sakari Poussa, Intel, I work on Tizen 13:21:25 kenneth_: Kenneth Christiansen, Tizen, I work on the web platform 13:21:36 zkis: Zoltan Kis, Intel, I work on Telephony 13:22:02 gmandyam: Giri Mandyam, Qualcomm Innovation Center 13:22:25 Dong-Young: Dong-Young Lee, LGE 13:22:41 Joonhyung_Kim: Joonhyung Kim, LGE 13:22:54 Oliver: OliverX, Gemalto 13:23:02 kjwallis: Ken Wallis, BlackBerry, WebWorks 13:23:13 Olivier Potonniee, Gemalto 13:23:14 darXX: XZ 13:23:19 dsuwirya: Darmawan Suwirya, Gemalto 13:23:22 genelian: Gene Lian, Mozilla, QQ 13:23:30 JonathanJ1: Jonathan Jeon, ETRI, most apis 13:23:40 lgombos: Laszlo Gombos, Samsung, Tizen 13:23:54 Claes: Claes Nilsson, Sony Mobile, I'm the editor of the raw socket api 13:24:10 hsinyi: Hsin-Yi Tsan, Mozilla 13:24:42 KuiJongLee: Kui-Jong Lee, Mozilla 13:25:05 Joonhyung has joined #sysapps 13:25:08 dsr: Dave Raggett, W3C, the staff contact for the group, here to help make the group work well 13:25:45 anssik: Anssi Kostiainen, Intel, trying to get specs forward 13:25:55 ... willing to commit a lot of time to get things done 13:26:20 Chengyan: Chengyan Zhang, China Unicom 13:26:26 Bo_CHEN: Bo Chen, China Unicom 13:26:56 Marta: Marta Px, Samsung 13:27:06 Janusz: Janusz Majnert, Samsung 13:27:22 wonsuk_: Wonsuk Lee, Samsung, CoChair, interested in most topics 13:27:37 ... i hope that we can talk about time frames of specs in this meeting 13:27:43 ... we embedded the schedule in the charter 13:27:57 ... even if we make good specs, we also need to consider timeframe 13:28:16 jungkees: Jungkee Song, Samsung, interested in all APIs, but especially Runtime and Manifest 13:28:25 chris has joined #sysapps 13:28:37 Daniel: Soohong Park (Daniel), Samsug, interested in AA 13:29:01 mounir: Mounir Lamouri, Mozilla, CoChair 13:29:14 s/Samsug/Samsung/ 13:29:24 jmajnert has joined #sysapps 13:29:26 Joonhyung has joined #sysapps 13:30:31 Marta has joined #sysapps 13:30:46 q+ 13:30:49 q- 13:30:52 q? 13:30:55 q+ 13:30:56 q? 13:30:57 i/irc/Topic: Explanation of how to use meeting/ 13:31:00 q- 13:31:01 q? 13:31:01 q= 13:31:06 queue= 13:31:27 Zakim, what is the code? 13:31:27 the conference code is 79727 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), timeless 13:31:41 timeless has changed the topic to: the conference code is 79727 (tel:+1.617.761.6200 sip:zakim@voip.w3.org) 13:32:18 topic: App URI 13:32:23 marcosc: i think the spec is ready for LC 13:32:29 ... i don't think there are any outstanding technical issues 13:32:34 ... just looking at what's left in github 13:33:22 mounir: we're just trying to say "hi, i'm here" ... not go into too much detail 13:33:32 marcosc: these are the only issues needed to get to LC 13:33:46 ... big thank you Marta for help with the test suite 13:33:55 ... we received an offer from a person who put together a URL test suite 13:33:59 ... it's fairly extensive 13:34:05 http://app-uri.sysapps.org/ 13:34:08 ... it was reviewed by anne, the editor of the url spec 13:34:15 ... we'll see if we can layer our tests on top of that 13:34:20 q+ to ask about implementation status 13:34:23 ... i'd like to look at layering this spec with the Fetch spec 13:34:31 ... Fetch defines how to fetch stuff 13:34:44 ... in terms of Web Architecture, it'd be good to instead of redefining 13:34:49 ... integrate with that 13:35:02 ... to interoperate with what's in the platform 13:35:12 ... it isn't necessary to do that, because the spec is self contained 13:35:17 ... i don't think it'd affect conformance 13:35:22 ... i need to talk to anne about that 13:35:34 ... hopefully within the next month or so, we could publish it as LC 13:35:37 ... anyone have any comments? 13:35:50 ... is anyone apart from Mozilla interested in implementing this spec? 13:36:02 zkis: how do address other applications? 13:36:07 marcosc: other applications aren't covered 13:36:15 ... it's only for addressing resources within your package 13:36:19 q+ 13:36:22 ... there is no means to address another application 13:36:32 ... mozilla is currently... but not specifically working with that 13:36:45 ... defining an Origin in the manifest for privileged apps 13:36:55 ... which lets apps interoperate with the web 13:37:00 q+ 13:37:05 ... which lets apps work with CORS/other technologies 13:37:10 mounir: is that Origin random? 13:37:17 marcosc: no, that origin is set by the developer 13:37:23 ... if you don't specify it, you get a random origin 13:37:32 ... right now, i don't think we have a way for one app to communicate to another 13:37:36 ... it's very easy to forge 13:37:44 ... it requires a centralized registry to get it to work 13:37:56 ... it's ok with FirefoxOS, it's a proprietary platform, it's centralized 13:38:03 kenneth_: does Chrome have something similar? 13:38:11 marcosc: I think it uses chrome-app:, but it's essentially the same 13:38:18 ... i don't know if they have HTTP responses 13:38:23 ... we fake HTTP responses (404, etc.) 13:38:33 anssik: some people may not remember the widget: uri scheme 13:38:38 ... can you highlight the differences? 13:38:44 ... can the people on the line hear? 13:38:48 Zakim, who is on the call? 13:38:48 On the phone I see [Mozilla] 13:38:49 [Mozilla] has dsr, anssik, marcos, mounir, spoussa, kwallis, zoltan, wonsuk 13:39:25 marcosc: the differences are purely cosmetic-- find and replace 13:39:40 ... s/widget:/app:/g 13:39:46 ... all that feedback is already in the spec 13:39:57 anssik: this is rebranding, it's already been scrutinized (in WebApps) 13:40:07 RRSAgent, draft minutes 13:40:07 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html JonathanJ1 13:40:07 marcosc: yes, but with a Test Suite, and a TAG review 13:40:16 anssik: do you have Implementation Status from widget:? 13:40:29 marcosc: since we published it as a Note, I don't think we have that list 13:40:41 mounir: what's the implementation status of app:? 13:40:50 marcosc: it's only Mozilla, but there are some bugs 13:40:54 q+ 13:40:58 Marta: 6 failed out of 20 tests 13:41:15 q- 13:41:16 ... and something for Tizen based on file:, but even worse 13:41:20 marcosc: only us at the moment 13:41:24 mounir: about Origin 13:41:35 ... according to the spec, Origin is random 13:41:42 ... but Mozilla had issues about that 13:41:51 ... because the security model of the web is based on origin 13:42:04 marcosc: uuid is only a recommended, it isn't mandated 13:42:13 ... i'm going to change the example to make that more clear 13:42:17 +??P1 13:42:19 -??P1 13:42:19 +??P1 13:42:27 mounir: mozilla's solution was to add origin in the manifest 13:42:34 ... and a reviewer would have to approve that 13:42:54 ... so if you have a Google Maps app, the reviewer could say it matches maps.google.com and approve 13:43:02 ... where would Origin specification be? 13:43:08 marcosc: it would be in the Manifest spec 13:43:10 q? 13:43:16 ... but i should add a note indicating that it's outside the scope of this document 13:43:18 ack gmandyam 13:43:33 gmandyam: there's a normative dependency on Mime Sniff 13:43:47 q? 13:43:54 ... i've gotten conflicting feedback from W3 on normative dependencies outside W3 13:44:01 marcosc: that's why i'd like to layer it on Fetch 13:44:07 ... I think Fetch already has to deal with that 13:44:21 ... I'm not sure if URL is going to deal with it 13:44:25 ... there's also CSP 13:44:30 ... there's a lot of intermixing 13:44:36 ... you're right, the thing's a mess 13:44:43 ... the story for mime sniffing is a bit of a mess 13:44:48 q+ to ask about Fetch and W3C standardisation 13:44:49 gmandyam: I looked through XHR2 13:44:53 [for reference, pub history of the Widget URI scheme (now a Note) that predates the app URI scheme: http://www.w3.org/standards/history/widgets-uri] 13:44:59 ... XHR2 had a reference to Mime Sniff, but it was informative 13:45:08 ... you could follow their approach, of using informative 13:45:12 marcosc: i think that might be ok 13:45:14 q? 13:45:30 ACTION: file a bug about maybe relaxing dependency on sniff 13:45:30 Sorry, but no Tracker is associated with this channel. 13:45:32 q+ 13:45:35 ack anssik 13:45:48 ACTION: make it clearer that uuid is not a hard requirement 13:45:48 Sorry, but no Tracker is associated with this channel. 13:46:18 q? 13:46:49 s/KuiJongLee/thinker/ 13:47:13 s/Kui-Jong Lee/Kui-Fong (Thinker) Lee/ 13:47:30 gmandyam: today developers live with sites that don't follow Sniff 13:47:36 marcosc: Sniff applies on the client side 13:47:37 q- 13:48:07 gmandyam: app developers trust that content types are set correctly 13:48:16 marcosc: the trust is that something resembling Sniff is active 13:48:20 gmandyam: but it might not be Sniff 13:48:32 marcosc: the assumption of using a hard dependency is to guarantee Sniff 13:48:40 ... relaxing it will give you this pain 13:48:47 ... consider you're using a Proxy 13:49:04 ... if there's Sniff, it promises to use Sniff's magic number checks for binary types 13:49:13 ... you're guaranteed the appropriate behavior if you have a Must 13:49:23 ... it does have a semi annoying behavior that it's a semi living document 13:49:32 gmandyam: you can verify this in testability 13:49:37 marcosc: that's the idea 13:49:46 gmandyam: then you could say recommended, and rely on verification 13:49:53 marcosc: i'll have a look at what state it's at 13:50:01 ... for Mozilla/WebKit, they already implement Sniff 13:50:10 ... i don't know how consistent they are, i don't know the level of interop 13:50:15 ... but i suspect it's fairly high 13:50:24 q- 13:50:29 ... i don't think it matters if we relax it or make it stronger 13:50:33 ack zkis 13:50:33 ack zkis 13:50:52 zkis: you could give a location to get a file 13:50:58 ... can you access contact objects? 13:51:12 marcosc: no, this is just retrieving resources stored within the application package 13:51:21 ... other objects may define their own ways of being addressed 13:51:33 ... we might even define a way to address contacts or others 13:51:35 ack mounir 13:51:35 mounir, you wanted to ask about Fetch and W3C standardisation 13:51:56 mounir: will Fetch move to W3? 13:52:07 Josh_Soref: [mumbles] probably not 13:52:13 marcosc: i trust that anne will do the right thing 13:52:24 ... i think they're doing the thing in good faith 13:52:32 ... these specs will need to move to W3 13:52:39 ... especially if Navigation Controller will depend on Fetch 13:52:47 ... when Navigation Controller moves to W3 13:52:54 s/[mumbles] probably not// 13:53:09 ... I spoke w/ MikeSmith, and he said Navigation Controller would be a good fit to move to W3 13:53:12 Daniel_ has joined #sysapps 13:53:13 ... that's a replacement for App Cache 13:53:18 q? 13:53:23 ... i'd assume its dependencies would come along 13:53:49 mounir: Is anyone here interested in implementing that spec? 13:53:57 kenneth_: we have a patch for it internally 13:54:42 Josh_Soref: I believe Cordova is/has/will be 13:55:01 mounir: do you know if we can get Google to implement? 13:55:14 marcosc: i don't know, they're using it for Extensions and Packaged Apps 13:55:25 RRSAgent, draft minutes 13:55:25 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 13:55:25 ACTION: contact Google to see if they would be interested to implement this specification 13:55:26 Sorry, but no Tracker is associated with this channel. 13:55:43 marcosc: i'd like to get a resolution to move this toward LC 13:55:43 +1 13:55:52 +1 13:55:54 +1 13:56:12 mounir: some people want to access Zip files 13:56:23 ... what would be the difference between the app: and direct access to a Zip file 13:56:35 marcosc: there have been numerous attempts to do this over 20 years 13:56:43 ... addressability of 13:56:51 ... with a Zip file, you could get the files 13:57:00 ... or get a file from inside the server 13:57:07 ... it should be completely transparent 13:57:15 ... like a #!/ to get the file you want 13:57:33 ... i don't think you should use a uri, just http 13:57:38 ... zip file #! / 13:57:42 mounir: close to the jar: scheme 13:57:58 marcosc: the fallback solution there is, if it doesn't support the type, it just requests it from the server 13:58:14 ... or it could be clever and download the file locally and address the file as if it's http 13:58:18 q+ 13:58:21 ... how it handles mime types gets complicated 13:58:34 mounir: one of the main reasons for app: was for security reasons 13:58:43 ... the origin for jar: was the origin of the .zip 13:58:51 ... but origin: for app: is random which protects the site 13:58:58 ... this seems like the main difference between direct access 13:59:06 ... but if origin randomization isn't a mandatory bit 13:59:20 marcosc: app: assumes you're starting from a local non-web environment 13:59:33 ... but a larger way of accessing assumes you're starting from the web and accessing inside 13:59:40 ... that would be the main difference 13:59:48 q? 14:00:37 ack jungkees 14:00:40 Josh_Soref: the problems mozilla hit were that people could smuggle .zip content into random file kinds 14:00:49 ... which violated the security assumption of file hosters 14:00:56 ... Microsoft got hit by that w/ .chm 14:01:27 ... And then there's Google's headache where there were two ways to index .zip files, and they validated the way they weren't accessing, which was (and still is) a huge security hole 14:01:46 wonsuk_: XHR doesn't actually talk about Sniffing 14:02:03 marcosc: XHR does a bunch of overrides 14:02:16 s/wonsuk_/jungkee 14:02:18 ... it does a lot of rewriting of mime types 14:02:21 q? 14:02:25 s/wonsuk_/jungkee/ 14:03:02 Topic: Raw Sockets 14:03:10 Claes: i think we're expecting remote participants 14:03:15 ... what about sicking? 14:03:16 Zakim, who is on the phone? 14:03:16 On the phone I see [Mozilla], ??P1 14:03:18 [Mozilla] has dsr, anssik, marcos, mounir, spoussa, kwallis, zoltan, wonsuk 14:03:52 Zakim, P1 is chris 14:03:52 sorry, timeless, I do not recognize a party named 'P1' 14:03:55 Zakim, ??P1 is chris 14:03:55 +chris; got it 14:04:31 lgombos: chris, can you hear us? 14:04:37 chris: yes, i can hear you 14:04:41 [ we can hear chris too ] 14:04:53 i/can you/Topic: Alarms/ 14:05:03 lgombos: i think someone should try to drive the discussion 14:05:10 marcosc: chris, i'll try to drive the discussion 14:06:07 ... the spec has been renamed from WebAlarms to TaskScheduler 14:06:16 s/Topic: Alarms/Topic: Task Scheduler/ 14:06:39 largest outstanding issue - https://github.com/sysapps/web-alarms/issues/46 14:06:44 zkis: because the change of context, it doesn't really deal with time zones 14:06:50 marcosc: not as much as it did before 14:06:59 ... not in the web that you'd expect a calendar application to support time zones 14:07:15 ... Marta did a formal survey to find out if anyone understood respect/ignore-timezones 14:07:18 ... no one understood 14:07:27 ... mounir did a survey of Firefox OS 14:07:33 ... no one understood there either 14:07:38 ... they used the wrong one 14:07:46 ... the first big issue is 14:07:54 ... do we want to support the Calendaring UCs or not 14:07:56 s/mounir did a survey of/mounir did a grep on/ 14:08:05 ... should you be able to build a Calendar app on this? 14:08:12 ... let me frame it differently 14:08:17 ... to make this useful for Time Zones 14:08:23 q+ 14:08:31 ... you'd want to be able to say "remind me of this meeting that's happening at 5pm GMT+5" 14:08:39 ... whether that's calendaring, it seems useful to be able to do that 14:08:54 ... although that seems useful, whether people will implement that, without falling back to the system to handle that complexity 14:08:59 ... you need to deal with time zones 14:09:00 q+ 14:09:13 ... Josh_Soref brought up +13, and +:15 14:09:21 ... you need to define a micro syntax for timezones 14:09:26 initial implementor feedback form blink-dev - https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/kbBbordYkjk 14:09:27 ... plus leap years, DST 14:09:30 ... the OS usually handles that 14:09:38 ... i imagine a lot of that is solved 14:09:52 Josh_Soref: countries like to screw that every year 14:10:05 marcosc: it's whether it's feasible 14:10:10 zkis: date doesn't support time zone 14:10:21 mounir: Date knows its timezone, but doesn't let you set one 14:10:30 ... some people want to remove date from the web 14:10:36 ... you add an alarm, 14:10:46 ... if you create an alarm now, the system will know you're in Toronto 14:10:50 ... the system knows that 14:11:00 ... but you might want to say "9am" or "9am in eastern tz" 14:11:10 ... we could pass a milliseconds since epoch 14:11:15 q? 14:11:20 ... and pass a string "America/Toronto" or nothing (UTC) 14:11:24 ... it's a bit more painful 14:11:29 ... you have to handle ms 14:11:38 ... but ECMAScript thinks no one should use Date 14:11:47 ... then you have no tz except UTC 14:11:49 Josh_Soref: +1 14:12:02 marcosc: the ECMAScript guys said don't use Date 14:12:02 RRSAgent, draft minutes 14:12:02 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html JonathanJ1 14:12:11 ... and WebIDL says it's AT-RISK 14:12:20 marcosc: to me it seems horrible 14:12:30 mounir: that's what people in ECMAScript want us to use 14:12:44 marcosc: ms is just a number? ok, yes 14:12:57 Josh_Soref: you only have Date.now() 14:13:08 marcosc: you say Date.now() +/- x 14:13:18 ... at this time in ms, in this timezone (GMT+5), do this 14:13:31 zkis: this is fine for short events, but for recurring 14:14:06 this is fine for one-shot events, but NOT for recurrent events 14:16:00 q? 14:16:05 q+ 14:16:30 Josh_Soref: there's an approach where you schedule callbacks for a couple of the likely timezones (the earliest one, perhaps 4 or 12 hours later) 14:16:50 mounir, for now yes 14:17:01 ... you wake up at the first callback, you check your timezone, and decide whether the event will happen soon in your timezone, if so you set a new event for shortly before the actual right time 14:17:05 but at the moment, nothing is happening right? 14:17:07 ... if it's "now", you do your real work 14:17:13 ... if it's later, you sleep 14:17:40 ... this is easy to explain, and any repetition logic or complex repetition is handled by your code scheduling for the next date, be it "4th monday of the month" or "last monday of the month" 14:17:58 ... it's a series of one-shots, but if we promise to call you at some point, you're fine, no need to schedule all of them, a few will do 14:18:06 ... easy to explain, easy boilerplate for the scheduling 14:18:23 ... and easy to integrate the complicated app specific repetition logic 14:18:26 ack zkis 14:18:31 ack gmandyam 14:19:00 gmandyam: this was never intended to be a Calendar API 14:19:04 ... we established that early on 14:19:15 ... if you want to do a Calendar API, you can look at DAP 14:19:18 ... it's quite complicated 14:19:29 ... i personally object to us making this a requirement for this API, i think it's outside of scope 14:19:36 ... i think the discussion of recurrence is nice 14:19:44 ... i agree with Josh_Soref, an application can do this with the existing API 14:19:50 ... we can come up with code examples all day long 14:19:57 ... for the spec, i think we only need minimal examples 14:20:06 ... i think we have sufficient time zone examples in the spec 14:20:17 ... chris put them in the spec based on Josh_Soref 's and my comments last fall 14:20:23 ... i don't know why they keep coming up 14:20:28 marcosc: because we see it in real apps 14:20:39 ... it's a problem, people don't understand it 14:20:49 ... when Marta asks a small set of developers "do you understand this" 14:20:53 mounir: the spec is clear 14:20:57 thinker has joined #sysapps 14:20:57 ... but people don't read the spec 14:21:09 ... if you want to use an API, you read a tutorial, or copy-paste 14:21:16 ... that parameter is not intuitive at all 14:21:24 gmandyam: the HTML5 spec is sparse 14:21:33 ... but there's an article on HTML5Rocks 14:21:40 ... that could be one approach, if someone's willing to do it 14:21:55 ... but answering developer confusion in the spec 14:22:03 ... if developers are giving it a quick once through 14:22:14 marcosc: i read through it, implemented it, and got it wrong 14:22:18 ... i consider myself an average developer 14:22:23 ... i'm not representative 14:22:32 ... what we've seen is that it shouldn't be so bad 14:22:48 ... chris has proposed alternative names (followSystemTimezone / useSystemTimezone) it may be more clear 14:22:52 ... we need to test it on people 14:23:03 ... i take ergonomoics of APIs very seriously 14:23:10 ... we strive to make APIs as usable as possible 14:23:15 ... even if it takes more time 14:23:23 mounir: at mozilla, APIs have to be self describing 14:23:31 ... you just read the IDL, you don't read tutorials 14:23:39 ... that argument... it came from _us_ 14:23:45 ... in the beginning, we had a boolean, it was even worse 14:23:53 ... we switched to a string, but people didn't understand the string 14:23:57 ... we're to blame, it was our idea 14:23:59 ... we want to fix it 14:24:05 gmandyam: is this syntactic sugar? 14:24:14 ... as long as the functionality doesn't fundamentally change 14:24:24 ... but people in this room were reviewing this 14:24:27 q/ 14:24:29 q? 14:24:32 marcosc: we're willing to spend extra time 14:24:35 s|q/|| 14:24:45 ... we want it to actually make sense 14:24:55 kjwallis has joined #sysapps 14:25:05 ... i think we have agreement that Calendaring is not in scope 14:25:15 mounir: i think Recurrence is not an issue 14:25:36 ... i think we should still consider writing a Calendar app based on the API is a UC, but it shouldn't be "easy", just "if you want to, you can do it" 14:26:00 ... you should be able to fire an event using the Task Scheduler API 14:26:14 zkis: once we agree that the API isn't recurrence, why have TZ at all 14:26:15 +1 to what mounir just said 14:26:28 mounir: for One shot, time zone is very useful 14:26:34 ... the first UC is i want "7:30am" 14:27:02 ... the second is that i woke up at 7:30am on the second day in Toronto (first day in London) 14:27:10 ... but if i have an event with my manager 14:28:11 zkis: do you need to deal w/ timezones at all? 14:28:21 mounir: the other issue is that you have to fetch time zone definitions 14:28:28 ... the system could take care of that for the app 14:28:41 zkis: if you decide to include timezone, it's one step to recurrence 14:28:46 mounir: i don't think they're related 14:28:58 `7am` M-F, and `9am` Sat 14:29:07 s/`7am` M-F, and `9am` Sat/... `7am` M-F, and `9am` Sat/ 14:29:17 ... i think recurrence and timezone are different problems 14:29:21 ... you don't seem to agree 14:29:27 q? 14:29:30 marcosc: i tend to agree with zkis 14:29:40 ... it's a step to add all sorts of things, but it's up to us to limit it 14:30:11 ... Respect the timezone, but when you specify the timezone for the alarm, it also gets complicated 14:30:34 zkis: there are events that update when timezone shifts or not 14:30:38 ... and others that don't 14:30:45 ... but at that point it's a calendar api 14:30:51 q? 14:31:18 mounir: maybe we could start without a timezone, and see how it works, but reserve a way to perhaps add it if necessary 14:31:31 ... i don't know, would Intel would be interested 14:32:05 chris: for TZ support 14:32:11 ... is mounir pushing for what's in the spec 14:32:16 ... or supporting any TZ, not just the system 14:32:29 marcosc: mounir is asking "can we try without TZs" at all -- initially 14:32:41 chris: what's it do internally? 14:32:45 mounir: ms since epoch 14:32:54 ... if you use Date.now(), 14:33:03 ... if you create a new Date in 9am, it's 9am in your TZ 14:33:12 ... because Date() shifts that to UTC 14:33:19 ... Chrome uses Date.now() 14:33:31 ... the don't have timezones, but they have repeat 14:34:05 ack anssik 14:34:24 s/the don't have/they don't have/ 14:35:07 anssik: things should be terminated 14:35:17 ... is there something in launchEvent 14:35:22 ... with a `reason` 14:35:33 ... it perhaps should be closer to the Runtime model 14:35:41 mounir: i thought it was using System Messages 14:35:47 anssik: i see references, but that's very underspecified 14:35:57 mounir: the Runtime spec is using System Messages 14:36:04 http://support.microsoft.com/kb/325413 : "Methods in these interfaces accept schedule time data in SYSTEMTIME format. The SYSTEMTIME format is not set for any local time zone. " 14:36:05 ... i guess the Message would be `Task` 14:37:18 I think 2 approaches would make sense: 1. task scheduler with no time zone support (i.e. using UTC), 2. calendar API supporting TZ and recurrence 14:37:52 mounir: to fire every hour 14:37:59 ... you create a new task for the next hour 14:38:06 anssik: have you talked about that in public? 14:38:19 mounir: mozilla was discussing with google, bu ti wasn't involved in that discussion 14:38:29 anssik: it would be great to get those individuals to contribute to this WG 14:38:52 q? 14:39:01 RRSAgent, draft minutes 14:39:01 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html JonathanJ1 14:40:14 kenneth_: we'd like something simple where something more complicated can be built upon 14:40:51 marcosc: i agree 14:40:57 mounir: we need to remove timezone, change Date to ms 14:41:34 ACTION: change the Task Scheduler spec to no longer have tz information 14:41:34 Sorry, but no Tracker is associated with this channel. 14:42:09 mounir: anything else? 14:42:17 marcosc: chris added text to support Promises 14:42:30 mounir: on the Promise text, I think you put Promise and then the precise return type 14:43:00 marcosc: that isn't in WebIDL yet 14:43:46 marcosc: Promises break Exception handling 14:43:52 ... WebIDL is supposed to do the type checking 14:44:04 ... but Promised based APIs, you aren't supposed to throw exceptions 14:44:12 ... you're supposed to send exceptions to the resolver 14:44:16 ... i raised this as an issue w/ webidl 14:44:20 ... there's also mounir 's issue 14:44:26 ... returning a Promise w/o a type 14:44:38 q? 14:44:47 q+ 14:45:42 kenneth_: i know with the Chrome approach, you need to resubscribe to the events on the next load 14:45:44 mounir: why 14:45:52 kenneth_: because it needs the function callbacks 14:46:31 ACTION: chris should open an issue so we keep in mind the relation between Task Scheduler and Event Pages 14:46:31 Sorry, but no Tracker is associated with this channel. 14:46:45 marcosc: one model is that pages are kept alive 14:46:53 kenneth_: they aren't workers, they're doclets 14:46:59 marcosc: right, they're rebuilt, and shut down 14:47:22 q? 14:50:02 marcosc: chris, anything else? 14:50:04 chris: nope 14:50:05 s/doclets/documents/ 14:50:09 :) 14:50:11 q? 14:50:16 q+ 14:50:18 ack genelian 14:50:44 http://web-alarms.sysapps.org/#taskscheduler-add 14:50:57 If an error occurs, run these substeps and then terminate these steps: 14:51:01 Let error be a new DOMError object whose name is "InvalidStateError" if the date argument is in the past, "QuotaExceededError" if the data argument exceeds an implementation-dependent size limit, and "UnknownError" otherwise. 14:51:33 genelian: the InvalidStateError, for an alarm in the past, i don't think this error is feasible for the API implementation 14:51:41 ... we can't check whether a date is expired 14:52:00 ... suppose you want an alarm for "7:00:01am" 14:52:08 ... and the call is at "7:00:00am" 14:52:27 ... the codepath could be processed very fast, possibly in 1s 14:52:42 ... but if the codepath needs more than 1s, then you will return an invalid state error 14:52:49 ... it's a race condition 14:52:59 ... i'd suggest removing this error 14:53:02 Yes, it is racy.. 14:53:13 ... and have the system always fire the event if it's in the past 14:53:15 Josh_Soref: +1 14:53:38 ACTION: chris should file a bug about the race condition 14:53:38 Sorry, but no Tracker is associated with this channel. 14:53:45 ?Q 14:53:47 q? 14:53:49 q? 14:53:51 ack wonsuk_ 14:54:01 wonsuk_: what's the timeframe for LC for this spec? 14:54:05 ... there are no big issues 14:54:08 marcosc: that we know of yet 14:54:14 ... i think the next step is to build the test suite 14:54:18 ... a small reference implementation 14:54:23 mounir: do we have any implementation? 14:54:24 marcosc: no 14:54:31 mounir: no one is implementing this spec 14:54:33 ... not even mozilla 14:54:40 Marta: i started working on a JS impl 14:54:49 marcosc: ... using setTimeout 14:54:57 marcosc: there's no real implementation 14:55:10 ... LC can mean "we think it's Feature Complete" 14:55:14 mounir: sure, we can move to "LC" 14:56:02 mounir: i don't think it's very important 14:56:08 marcosc: it's important to free up a slot 14:56:10 ... to do other work 14:56:13 wonsuk_: yes 14:56:27 kenneth_: i'd like to see how everything works together with the Event Pages model 14:56:43 marcosc: it doesn't exist 14:56:53 http://developer.chrome.com/apps/event_pages.html 14:56:56 anssik: can we schedule some time for Thursday to talk about that 14:57:05 mounir: to me, it's part of Runtime/Security 14:57:11 http://anssiko.github.io/runtime/app-lifecycle.html <- the event page model in other words 14:57:13 anssik: kenneth_ and i wrote up a proposal 14:57:28 q? 14:57:30 s|http://anssiko.github.io/runtime/app-lifecycle.html <-|-> http://anssiko.github.io/runtime/app-lifecycle.html| 14:57:34 RRSAgent, draft minutes 14:57:34 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 14:57:36 [ Break ] 14:58:48 s/?Q// 14:59:19 bug filed for genelian's comment: https://github.com/sysapps/web-alarms/issues/51 15:00:28 s/XHR doesn't actually talk about Sniffing/gmandyam talked about WhatWG's XHR2 Mime Sniffing. Because it's outside W3's context, that's why there isn't a full reference in the URI spec. But XHR2 doesn't refer to Mime Sniffing -- It uses overrideMimeType()/ 15:00:31 RRSAgent, draft minutes 15:00:31 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 15:03:01 s|mounir, you wanted to ask about Fetch and W3C standardisation|-> http://fetch.spec.whatwg.org/ mounir, you wanted to ask about "Fetch" and W3C standardisation| 15:03:03 RRSAgent, draft minutes 15:03:03 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 15:05:31 s|-> http://fetch.spec.whatwg.org/ mounir, you wanted to ask about "Fetch" and W3C standardisation|mounir, you wanted to ask about Fetch and W3C standardisation| 15:05:49 RRSAgent, draft minutes 15:05:49 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 15:06:38 s|will Fetch move to W3?|-> http://fetch.spec.whatwg.org/ "Fetch" -- will it be moved to W3C for standardisation?| 15:06:41 RRSAgent, draft minutes 15:06:41 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 15:07:33 s|"Fetch" -- will it be moved to W3C for standardisation?|Fetch -- will this be moved to W3C for standardization?| 15:07:34 RRSAgent, draft minutes 15:07:34 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 15:21:22 mounir: any more questions about Task Scheduler? 15:21:25 q? 15:21:48 dsuwirya: i was assuming the time would be an Interval 15:21:49 rrsagent, set logs public 15:21:55 rrsagent, make minutes 15:21:55 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html dsr 15:21:58 ... instead of a thing from epoch 15:21:59 lgombos has joined #sysapps 15:22:05 ... you want to do something at an interval 15:22:16 ... even if you want to wake up the system at a time 15:22:17 lgombos_ has joined #sysapps 15:22:30 ... you're more likely to do it based on Now instead of epoch 15:22:42 ... it avoids the problem with time in the past 15:22:44 JonathanJ1 has joined #sysapps 15:22:50 lgombos has joined #sysapps 15:22:52 ... maybe there's a timezone change event 15:23:05 ... and the application takes care of recomputing intervals 15:23:20 ... it's good to make the api of the system lightweight 15:23:27 ... does that make sense? 15:23:46 mounir: this fixes the race issue 15:23:55 ... if you say "make it happen in 1 minute" 15:24:00 ... but if it registers very late 15:24:11 ... your thing could be fired a minute after it is registered 15:24:17 ... i think the race issue could be fired even later 15:24:24 ... if you say 8pm tonight 15:24:48 ... if you say "register for 10 hours", but if you're under pressure, you could fire at 8:05pm 15:24:55 ... i think you introduce more trouble than you fix 15:25:16 genelian: you need time to calculate intervals, so that's another race 15:25:31 mounir: setInterval() has no precision 15:25:37 ... it's a common bug on the web 15:25:44 ... they don't compute the delta between two calls 15:25:59 ... so i think we lose 15:26:04 ... i generally don't agree with that proposal 15:26:08 zkis: i agree w/ mounir 15:26:25 q+ 15:26:26 ... we don't have any way to do guaranteed response times from the system 15:26:28 ack chris 15:26:42 q+ marcosc 15:26:51 chris: i'm ok w/ removing the TZ from the specification 15:26:56 ... we can't do an alarm clock application 15:27:05 ... it's basically a setTimeout that can launch the app 15:28:44 Josh_Soref: if i use an alarm clock, it shouldn't set an alarm for 8am, it should fire for 7:55am, build up enough bits, and then fire the actual sound at 8am. otherwise, if it wakes up at 8am, the alarm will lag significantly 15:28:54 mounir: we discussed a timezone change api 15:29:02 ... you can already get timezone changes from new Date() 15:29:19 mounir: i think we fixed the bug w/ new Date() TZ 15:29:25 q+ 15:29:32 mounir: you could fire the Event Page 15:29:46 q- 15:29:51 [ there was a discussion where marcosc forgot that this isn't System Messages starting a UI, but Event Pages which start out w/o UI ] 15:30:05 q? 15:30:09 ack Dong-Young 15:30:21 Dong-Young: do we need ms or just s accuracy? 15:30:28 ... for most UCs, i think s is enough 15:30:30 ... second 15:30:39 ... I assume, if we have a task scheduled for 8am 15:30:43 ... but the machine is off 15:30:48 ... if it turns on at 9am 15:30:52 ... will the task be fired? 15:30:58 ... do we explicitly mention it in the spec? 15:31:03 mounir: i think we specify that 15:31:15 marcosc: it was guaranteed with system messages (via queuing) 15:31:24 mounir: chris and i spoke about it 15:31:40 ... the same problem happens if you change your time manually 15:31:46 ... 9am->10am 15:31:50 ... i think it's part of the spec 15:31:57 jungkees: that is specified in Runtime 15:32:03 chris: it's part of the examples 15:32:11 mounir: i think we should make that part of the spec 15:33:44 ACTION: make clear that a missed alarm should be fired 15:33:44 Sorry, but no Tracker is associated with this channel. 15:33:58 mounir: Timestamp uses ms, it's a standard 15:34:01 ... no point in moving 15:34:08 q+ 15:34:28 mounir: i'm not sure what precision is promised 15:34:30 ack chris 15:34:35 chris: i don't think there's any precision promised 15:35:29 ACTION: precise the precision ;) 15:35:29 Sorry, but no Tracker is associated with this channel. 15:35:40 For the second question, Rumtime spec says, When a UA is required to fire a system message of a given type, it has to do one of these actions: Otherwise, if the application is not running, the UA MUST add the message to the pool of messages and start the application. 15:35:52 q+ 15:35:57 ack chris 15:36:07 chris: there are already open issues on github 15:36:14 https://github.com/sysapps/web-alarms/issues/14 15:36:16 https://github.com/sysapps/web-alarms/issues/13 15:36:46 s|https://github.com/sysapps/web-alarms/issues/13|-> https://github.com/sysapps/web-alarms/issues/13 Specify behavior when clock jumps past an alarm| 15:36:58 s|https://github.com/sysapps/web-alarms/issues/14|-> https://github.com/sysapps/web-alarms/issues/14 Specify what happens when several alarms fire while device is off| 15:37:01 RRSAgent, draft minutes 15:37:01 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 15:37:05 q? 15:37:23 mounir: anything else on this topic? 15:37:33 Topic: Raw sockets 15:37:44 mounir: i invited sicking to attend by email 15:38:14 spoussa has joined #sysapps 15:38:16 no problem :) 15:38:23 s/no problem :)// 15:38:46 http://raw-sockets.sysapps.org/ 15:39:08 s|http://raw-sockets.sysapps.org/|-> http://raw-sockets.sysapps.org/ Raw Socket API| 15:39:09 Zakim: who is on the call? 15:39:22 zakim, who is on the call? 15:39:22 On the phone I see [Mozilla], chris 15:39:23 [Mozilla] has dsr, anssik, marcos, mounir, spoussa, kwallis, zoltan, wonsuk 15:39:41 s/Zakim: who is on the call?// 15:40:22 Claes: this API is for apps to communicate over UDP and TCP 15:40:26 ... we have a FPWD 15:40:35 ... there are about 14 open issues 15:40:39 ... some could probably be closed 15:41:09 ... this session shouldn't go into too much detail 15:41:20 s/Sorry, but no Tracker is associated with this channel.// 15:41:25 s/Sorry, but no Tracker is associated with this channel.// 15:41:38 s/Sorry, but no Tracker is associated with this channel.// 15:41:38 s/Sorry, but no Tracker is associated with this channel.// 15:41:39 s/Sorry, but no Tracker is associated with this channel.// 15:41:40 s/Sorry, but no Tracker is associated with this channel.// 15:41:40 s/Sorry, but no Tracker is associated with this channel.// 15:41:41 s/Sorry, but no Tracker is associated with this channel.// 15:41:52 marcosc: for now, give us a general overview 15:42:02 trackbot, bye 15:42:02 trackbot has left #sysapps 15:42:13 Claes: Session 5 is about UDP 15:42:18 ... the next Section is TCP 15:42:21 s/Session/Section 15:42:27 ... the last part is Server 15:42:35 RRSAgent, draft mintues 15:42:35 I'm logging. I don't understand 'draft mintues', timeless. Try /msg RRSAgent help 15:42:38 RRSAgent, draft minutes 15:42:38 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 15:43:09 ... a few issues to talk about 15:43:23 ... one is a proposal to use URLs instead of an address+port 15:43:35 ... i'd suggest we start with a discussion on Secure Sockets 15:43:56 https://github.com/sysapps/raw-sockets/issues/10 15:44:18 s|https://github.com/sysapps/raw-sockets/issues/10|-> https://github.com/sysapps/raw-sockets/issues/10 Raw Socket API: Support for secure sockets| 15:44:36 Claes: what does a web system application really need 15:44:47 ... the conclusion is that we should start w/ the simple case 15:44:51 ... server authentication 15:44:57 ... an attribute is added 15:45:06 ... taken for TCP to indicate to use a secure channel 15:45:09 q+ OT: register for dinner tomorrow 15:45:20 q+ to ask ppl to register for dinner tomorrow 15:45:35 ... there's also a proposal to offer startTLS() or similar 15:45:52 ... and these would use the default certificate 15:46:02 ... i added a proposal for startTLS() or upgradeToSecure() 15:46:06 -chris 15:46:08 ... i made an attempt to define a Promise based method 15:46:14 ... i got comments from marcosc 15:46:20 ... basically, this is 15:46:28 ... this doesn't require any specific parameters 15:48:02 Claes: so there probably needs to be a way to specify a Host Certificate for each API that handles accepting TLS 15:48:13 ack mounir 15:48:13 mounir, you wanted to ask ppl to register for dinner tomorrow 15:48:47 http://www.framadate.org/studs.php?sondage=vo67qorlgox5fwvf&lang=en_GB 15:48:54 q+ 15:48:56 s|http://www.framadate.org/studs.php?sondage=vo67qorlgox5fwvf&lang=en_GB|| 15:49:03 marcosc: without going into the details of this 15:49:11 ... does anyone object to offering a way to secure the connection? 15:49:44 zkis: sicking suggested using PeerConnection 15:49:47 ... what's the need? 15:49:55 marcosc: can PeerConnection do IMAP? 15:50:06 gmandyam: the UC is existing backwards compat support 15:50:13 Claes: this is for supporting existing clients 15:50:21 zkis: if we do support Raw Sockets 15:50:30 ... then we should support Secure Sockets 15:50:47 Claes: 1. create a secure connection 15:50:54 ... 2. upgrade an insecure connection 15:50:58 marcosc: i don't anyone objects 15:51:07 gmandyam: on Upgrade 15:51:16 ... are there observed issues w/ proxies? 15:51:17 q? 15:54:04 Josh_Soref: there aren't any differences between this and a normal client using that same proxy 15:54:11 ... either the proxy works, or it's horribly broken 15:54:27 https://github.com/sysapps/raw-sockets/issues/22 15:54:43 RESOLUTION: group supports offering APIs for Securing Raw Sockets 15:54:49 s|https://github.com/sysapps/raw-sockets/issues/22|| 15:54:56 https://github.com/sysapps/raw-sockets/issues/22 15:55:18 s|https://github.com/sysapps/raw-sockets/issues/22|-> https://github.com/sysapps/raw-sockets/issues/22 async methods should return a Promise| 15:55:37 s/Raw Sockets/Raw Sockets - both initially and via an upgrade/ 15:55:53 Claes: our Asynchronous methods should be based on Promises 15:56:06 ... and then there was a question of.... which methods in Socket are Async, and which are Sync 15:56:15 ... the conclusion was that the only really async method is send() 15:56:44 zkis: does it depend on the protocol? 15:57:30 zakim, who is on the phone? 15:57:30 On the phone I see [Mozilla] 15:57:31 [Mozilla] has dsr, anssik, marcos, mounir, spoussa, kwallis, zoltan, wonsuk 15:58:14 Claes: i'm not sure the benefit/how it would look like to have receive data as a Promise 15:58:18 ... i can't see how that would be modeled 15:58:55 Claes: the current design of send() is based on Node.js's Send API 15:58:59 ... it looks the same 15:59:06 ... Mozilla's Firefox OS api has the same syntax 16:01:11 Claes: we could make this a Promise APIs 16:01:24 ... i don't see a difference 16:01:30 ... one difference is not using Exceptions 16:01:47 q? 16:02:24 marcosc: Node.js is mostly server side 16:02:36 ... i think we need to reach out to them, to get them to look at this 16:02:44 ... they've iterated over their APIs quite a bit 16:02:48 ... they're pretty confident 16:02:54 ... and there are a bunch of libraries that do this as well 16:03:02 ack gmandyam 16:03:28 mounir: is there an implementation status? 16:03:39 marcosc: we could do a reference on top of node 16:03:54 Claes: i can take an action 16:04:07 spoussa: Intel is looking into the implementation as well 16:04:46 ACTION: make an implementation reference 16:04:50 marcosc: we should try 16:04:57 ... but it does look like it could be promisable 16:05:09 https://github.com/sysapps/raw-sockets/issues/17 16:05:47 s|https://github.com/sysapps/raw-sockets/issues/17|-> https://github.com/sysapps/raw-sockets/issues/17 address + port vs uri| 16:06:06 Claes: there's a discussion of using a URI scheme instead of arguments for address and port 16:06:12 ... i'm not convinced on the benefits 16:06:20 marcosc: i didn't see any strong arguments 16:07:03 q+ 16:08:32 Josh_Soref: the configuration of the two pieces is usually fairly far away from the socket bind call, and having to pass them separately can be somewhat error prone 16:08:47 ... but i don't personally care 16:09:10 Claes: sicking argues it doesn't give any value 16:09:22 ... the application should just do string concatentations to get a url 16:09:30 Claes: my proposal is to leave it for now 16:09:44 wonsuk has joined #sysapps 16:10:12 marcosc: anne was saying to use URL instead of URI to ensure that things are parsable 16:10:22 mounir: do we need public-script-coord@ to comment? 16:10:27 marcosc: it's more of a TAG issue 16:10:40 mounir: do we need a higher level feedback for this? 16:10:46 marcosc: i'm w/ Claes on not doing that now 16:11:04 ... this only covers a small part of URL space... no path, no fragment identifiers -- what does that mean 16:11:08 ... it's shoehorning 16:11:14 ... yes there's overlap w/ URL scheme 16:11:21 ... it feels like a good thing, but you don't really need it 16:11:26 ... it's just an address and a port 16:12:17 q? 16:12:28 ack gmandyam 16:12:32 gmandyam: i think this is an IETF issue 16:12:53 ... i think the way he described it doesn't describe sufficiently 16:12:58 ... there are a lot more parts to resolution 16:13:08 kjwallis has joined #sysapps 16:13:13 ... i think we should give feedback to the requester about the implementation cost 16:13:53 Claes: general opinion? 16:13:59 gmandyam: close 16:14:12 marcosc: defer -- come back to later... if it fits later 16:14:22 I think this issue should be closed for 2 reasons: (1) This should be proposed in the IETF, and (2) The resolution of URL's is not addressed in the proposal (e.g. DNS entries, etc.) 16:14:28 mounir: i'd want to reach out to some other group, but defer 16:14:35 And (2) above also belongs in the IETF 16:14:35 Claes: i'll close the issue w/ a comment 16:14:58 RESOLUTION: close the udp/tcp scheme issue 16:15:36 http://lists.w3.org/Archives/Public/public-sysapps/2013Aug/0068.html 16:16:14 Claes: Patrick McManus from Mozilla sent detailed comments 16:16:59 ... Patrick said please don't use the word "raw" 16:17:18 ... that's a well known networking term which is reserved for layers below TCP/UDP 16:17:28 ... he proposes renaming TransportLevelSocket 16:18:51 http://farm9.staticflickr.com/8228/8588917762_a848f72b09_o.gif 16:19:00 RRSAgent, draft minutes 16:19:00 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html JonathanJ1 16:19:25 s|http://farm9.staticflickr.com/8228/8588917762_a848f72b09_o.gif|-> http://farm9.staticflickr.com/8228/8588917762_a848f72b09_o.gif osi-7-layer-model| 16:20:53 mounir: make sure you have a filed issue for the rename 16:21:08 Claes: is there any problem with renaming specs? 16:21:11 ACTION: file an issue for Raw Sockets renaming 16:21:15 [ No, Alarm was renamed without issue ] 16:21:33 Claes: will there be 2 groups tomorrow? 16:21:37 mounir: 2 or 3 16:22:13 Claes: does anyone else have issues to discuss today? 16:22:27 gmandyam: what about TCP NO DELAY? 16:22:33 Claes: yes, that was a comment from Patrick 16:22:38 ... yes, i guess we should have that option 16:22:50 ... that's just a new field in the dictionary for TCP Options 16:23:03 ... i can take patrick's comments and file issues for them for tracking 16:23:31 mounir: what's left to do? 16:23:35 Claes: the main thing is secure sockets 16:23:51 ... I hope to get more support from 4D 16:23:51 s/what's left to do?/what's left to do in order to move to LC?/ 16:24:25 q? 16:26:35 can a compliant implementation not have secure sockets supported ? 16:27:26 My view is that this is optional but it has to be clarified. 16:27:57 lunch break 16:47:45 kjwallis_ has joined #sysapps 17:02:12 lgombos has joined #sysapps 17:14:26 jmajnert has joined #sysapps 17:23:09 lgombos has joined #sysapps 17:30:54 Zakim, who is on the call? 17:30:54 On the phone I see [Mozilla] 17:30:55 [Mozilla] has dsr, anssik, marcos, mounir, spoussa, kwallis, zoltan, wonsuk 17:31:14 +??P1 17:31:16 -??P1 17:31:16 +??P1 17:32:18 https://wiki.mozilla.org/WebAPI/DataStore 17:32:52 jungkees has joined #sysapps 17:32:59 Zakim, [Mozilla] also has Josh_Soref, kenneth_, zkis, gmandyam, Dong-Young, Joonhyung, opoto, genelian, dsuwirya, lgombos, Claes, hsinyi, Marta, jmajnert, Daniel 17:32:59 +Josh_Soref, kenneth_, zkis, gmandyam, Dong-Young, Joonhyung, opoto, genelian, dsuwirya, lgombos, Claes, hsinyi, Marta, jmajnert, Daniel; got it 17:33:12 Topic: WebAPI/DataStore 17:33:19 s|WebAPI/|| 17:33:27 Daniel_Samsung has joined #sysapps 17:33:34 mounir: one application owns a store 17:33:42 ... others are allowed to be `readonly`, or `readwrite` 17:33:55 ... the owner determines if a datastore can be readonly or readwrite 17:34:11 ... the owner will be able to write 17:34:26 ... the owner determines whether all other clients are readonly or all other clients are readwrite 17:34:38 ... this is a work in progress 17:35:06 ... you can have more than one store with a name 17:35:10 ... e.g. Contacts, or Messaging 17:35:21 ... a Skype application, a Facebook application 17:35:26 ... each could have a Messages store 17:35:46 ... an app could ask for access to all Messages stores, and assuming the user gives access to them, it gets access 17:36:19 ... our goal is to give no constraints about the data 17:36:31 ... the internal store of the data is a Sequence of elements with id's 17:36:33 ... 0..n 17:36:43 ... each element has an undefined structure 17:36:49 ... we expect people to write to the store "correctly" 17:36:56 ... and people to read the store "correctly" 17:37:07 ... we expect the owner to write "correctly" 17:37:19 ... and if clients are allowed to write, we expect them to write "correctly" 17:37:24 ... specifying types doesn't work 17:37:33 ... with JSON, you just write stuff 17:37:45 ... it would be unintuitive to say "i want this to be a number, this to be an object" 17:37:51 ... this would be very complex 17:38:27 ... for messaging/contacts 17:38:31 ... we'd need a way to sync 17:38:38 ... when you get a store object, the object knows its revision 17:38:43 ... an app can save its revision 17:38:59 ... and when the app is reopened, it can ask for changes between its revision and current 17:39:35 q+ Josh_Soref to ask how the client knows if there's another set of changes past the revision getChanges() gave 17:39:47 q+ 17:39:50 .... there will probably be a way to say "too many changes, start over" 17:40:05 s/..../.../ 17:40:14 ... internally, we had issues w/ Messaging App 17:40:23 ... one thing wanted to show unread count in the tree view 17:40:28 ... and the name of the contact, and the icon 17:40:33 q? 17:40:36 ... the Messaging App was working like crap 17:40:41 ... we need something that works fast 17:41:00 ... the Messaging App gets the system store of Messaging and the system store of Contacts 17:41:12 ... it will be backed with indexedDB 17:41:15 ... the data will be copied 17:41:23 ... but this guarantees fast access to the data 17:41:26 ... and simple sync 17:41:51 ... the manifest has a description 17:42:28 Josh_Soref: what if you want to show the description in various languages 17:42:40 mounir: the manifest will have localization bits 17:42:49 marcos: you can do it, but... 17:43:05 ... we looked at localization, it gets tricky, and it looks a little silly 17:43:14 ... the structure gets nested like 5 times 17:43:20 mounir: if you have a better idea, we're open to it 17:43:27 ... it could be pretty ugly 17:43:45 q? 17:43:45 q? 17:43:52 q+ 17:43:55 marcos: there's a larger architectural question 17:44:02 ... why are the descriptions there in the first place 17:44:12 mounir: we have descriptions because the security model 17:44:18 ... take Facebook, it has contacts 17:44:26 ... my app asks to get `contacts` data stores 17:44:36 ... there are two contacts stores... system -- linked to contacts api 17:44:39 ... and the facebook api 17:44:52 ... but you need a ui that says do you want `mounir-app` to have access to Facebook contacts? 17:45:05 marcos: but i could use the wrong description 17:45:10 mounir: no, the system pulls this information 17:45:22 ... for system stuff, we can write our own things 17:45:33 q+ 17:45:36 ... for foobar, we can't handle it 17:45:47 mounir: right now, our implementation 17:45:52 ... will limit that to readonly stores 17:46:00 ... if you have a writeable store (not readonly) 17:46:06 ... and anyone can write it 17:46:09 ... we'll ignore it 17:46:28 ... it doesn't seem trivial to make a ui request for "do you want to allow writes to the facebook contacts" 17:46:41 q? 17:46:54 q+ 17:47:04 Josh_Soref: why not have a function on the app which answers what is the description 17:48:24 q+ 17:48:42 ... for a localization that i haven't installed yet, it might be better to let the app just run and get an answer for what the new locale description 17:48:53 mounir: you might not have the latest update, but you should have it quickly 17:49:18 ... we'd love feedback for a web ecosystem 17:49:24 q? 17:49:28 ack Josh_Soref 17:49:28 Josh_Soref, you wanted to ask how the client knows if there's another set of changes past the revision getChanges() gave 17:50:52 mounir: at startup, you get the datastore 17:50:59 ... it's a reflection of the owner's store 17:51:13 ... you know the new version id 17:51:20 ... hopefully you saved the previous version id 17:51:23 ... you ask for changes 17:51:50 q? 17:51:50 Josh_Soref: but you first need to register for onchanges, or else it breaks 17:51:54 ack spoussa 17:51:54 mounir: sure 17:52:02 spoussa: about the object you're storing 17:52:11 ... that's different platform to platform? 17:52:20 ... if firefoxOS defines something 17:52:23 ... and someone else does something 17:53:07 mounir: the idea of the contacts api if we actually go to this 17:53:15 ... the contacts api would be saying Contacts has 17:53:29 ... Facebook would say 17:53:41 ... We don't have a feature that says 17:53:48 ... we don't have type verification 17:53:59 ... tinker mentioned this in Italy 17:54:03 ... we thought it was too complicated 17:54:04 marcosc has joined #sysapps 17:54:14 zkis: where do you specify these objects 17:54:22 q+ 17:54:22 mounir: for things from the System 17:54:38 ... here, owner will have a specific value, it could be "system" when it's from the system 17:54:46 ... it could be a specification 17:54:58 ... but if it's coming from a third party, we're expecting a third party to define it 17:55:20 q+ Josh_Soref to ask how an app determines if the service is really the service it thinks it is and not something impersonating 17:55:33 mounir: that's how the web works 17:55:37 ack zkis 17:55:48 zkis: do you have a special revision id for "i want all the data"? 17:55:59 ... if i want all the data, how do i get it? 17:56:08 mounir: you just use get() 17:56:17 marcosc: why have another method? 17:56:32 mounir: getChanges is about a diff 17:56:36 s/get()/getAll()/ 17:56:40 ... right now reivsionId is a uuid 17:56:53 q? 17:57:12 ... you don't want the full history of changes since the beginning of time 17:57:22 ... after some time, you'll clean your history 17:57:22 q+ 17:57:35 ... in that case, you don't want to say I've added all Ids 17:57:41 ... it's the same 17:57:47 zkis: what does getAll() return? 17:57:53 mounir: getAll() was not specified yet 17:58:07 ... it would be Promise getAll() 17:58:24 ... if getChanges() says it can't give you changes anymore, you drop what you have and use getAll() 17:58:35 zkis: can you get an object to get the schema of the datastore? 17:58:40 ... usually that's the case 17:58:47 ... if you had an introspection api... 17:58:50 ... that would be good enough 17:59:09 zkis: you could do forEach on the object to enumerate the properties 17:59:28 mounir: we thought storing the schema was not a good idea 17:59:36 ... i don't think it's very interesting to do 17:59:46 ... let's say you have a schema that says "everything here has this stuff"? 17:59:58 zkis: between two revisions, if you have changed the datastructures 18:00:13 mounir: with this api, two objects can have different schemas 18:00:29 q? 18:00:53 Josh_Soref: it's common to have union types in things 18:00:53 ack gmandyam 18:01:13 gmandyam: do you envision this api as a way to enumerate sim based contacts 18:01:14 [ laughter ] 18:01:23 mounir: this isn't really related 18:01:28 ... this api reflects how things are stored 18:01:35 ... if we want to enumerate sim based contacts 18:01:41 ... that should be in the Contacts API 18:01:48 ... and it's up to that API to decide how 18:02:42 mounir: if the Contacts API says that the system store of contacts should include contacts from SIM card 18:02:50 ... then it's up to the contacts api implementation 18:03:00 ... i think this should be up to a SIM API 18:03:19 gmandyam: in the last F2F, we decided that Contacts covered SIM 18:03:36 ... i just think it needs to be thought out more 18:03:47 q- 18:03:51 ... Second on Gallery. If this is meant to be a way to enumerate 18:03:54 ... Media 18:04:17 ... sicking had a comment about an application prepopulating the cache, which could be problematic 18:04:24 mounir: Gallery is a way to access pictures? 18:04:40 gmandyam: Pictures, Audio, Video, ... 18:04:44 q? 18:04:47 q+ 18:04:54 mounir: this wouldn't be related to Filesystems 18:05:00 ack genelian 18:05:14 genelian: curious about using this datastore API to deal with extension database 18:05:20 ... suppose system receives SMS message 18:05:28 ... does the system directly save the SMS into the database 18:05:36 ... and fire an onchange to the messenger app 18:05:58 ... or should the system fire an onreceive event and let the Messaging app use the add method to add the message back to the database 18:06:06 mounir: the system should save the message 18:06:41 ... for system, only the system would be allowed to write, not any apps 18:06:44 q? 18:06:46 q? 18:06:48 ack Dong-Young 18:06:49 ack Dong-Young 18:07:04 Dong-Young: why not use a shared version of indexedDB 18:07:06 [ laughter ] 18:07:11 mounir: that's a good question 18:07:19 ... this was not my first id 18:07:21 s/id/idea/ 18:07:27 ... it was to use indexedDB 18:07:34 ... sicking was strongly against using indexedDB 18:07:39 ... for reasons i can't remember exactly 18:07:48 ... you'd have issues regarding synchronization 18:07:54 ... even if you have one indexedDB thing 18:07:57 ... we want clients to copy data 18:08:06 ... and store data how they want and index it how they want 18:08:08 q+ 18:08:27 ... if you have one indexedDB, then they're likely to try to access it in ways for which it wasn't optimized 18:08:34 ... and it would be make synchronization more complex 18:08:44 ... i'm not sure it would add much benefit 18:08:51 ... if there's a reason to add benefit, we could think about it 18:08:54 q+ to ask about error handling on name clashes for data stores 18:09:18 Dong-Young: you're talking about synchronization when several applications share one database 18:09:27 mounir: at the first F2F, we had issues 18:09:31 ... and internally we had issues 18:09:37 ... if you're a Messaging App, and you want to find data 18:09:49 ... the performance issues are mostly related to how you index the data 18:09:54 q+ to ask what Mozilla expects SysApps to do with the datastore proposal 18:10:00 ... to make everyone happy, you'd have to index on everyone 18:10:25 s/on everyone/on everything/ 18:10:35 ... which would be horrible for performance 18:10:45 q+ dsr_ to ask about error handling on name clashes for data stores 18:11:00 Dong-Young: do we need to mandate id to be an int? 18:11:57 mounir: i think it's simpler to have id be an int 18:12:03 ... we could switch to something else 18:12:10 ... an integer makes the implementation easier 18:12:15 ... you can back that w/ a huge array 18:12:19 ... a string would require a hashmap 18:12:32 ... it seems like a bad idea, unless you have reasons 18:12:34 q? 18:12:36 ack Josh_Soref 18:12:36 Josh_Soref, you wanted to ask how an app determines if the service is really the service it thinks it is and not something impersonating 18:13:28 mounir: we use origin 18:13:34 Josh_Soref: could you change it to be called origin? 18:13:35 ack anssik 18:13:37 mounir: we could 18:13:44 anssik: did you prototype this? 18:13:46 mounir: i did not 18:13:51 ... someone at mozilla is implementing it 18:14:01 ... someone from the Firefox OS UI team is working on it 18:14:05 anssik: did you stress test it 18:14:08 https://bugzilla.mozilla.org/show_bug.cgi?id=871445 18:14:38 s|https://bugzilla.mozilla.org/show_bug.cgi?id=871445|-> https://bugzilla.mozilla.org/show_bug.cgi?id=871445 DataStore API| 18:14:44 anssik: who initiated this api? 18:14:45 mounir: me 18:14:56 ... at the F2F last time, we finished early (?) 18:15:18 ... sicking, tinker, KKS and i thought about this 18:15:52 s/KKS/genelian, and KKL/ 18:16:11 s/KKL/hsinyi/ 18:16:14 q? 18:16:15 ack zkis 18:16:23 zkis: Messaging had Filters 18:16:28 ... there were questions about efficiency 18:16:37 ... and there was a discussion that this is a synchronization api 18:16:49 ... it's pretty hard if it has to keep track of each revision 18:16:54 ... if it's an opaque id 18:17:13 mounir: getChanges can say "i don't have changes from that id -- you'll have to start over" 18:17:19 s/getChanges/getChanges()/ 18:17:22 JonathanJ1 has joined #sysapps 18:17:30 Zakim, [Mozilla] also has JonathanJ1 18:17:30 +JonathanJ1; got it 18:17:51 zkis: i proposed a timestamp 18:17:54 mounir: you could do that 18:18:00 ... but i think it's better if it's an opaque string 18:18:07 ... mozilla uses a uuid 18:18:17 ... we don't want people to guess 18:18:21 RRSAgent, draft minutes 18:18:21 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html JonathanJ1 18:19:08 timeless: there are privacy considerations, you don't want apps to know when there were changes 18:19:25 s/mounir/scribe/ 18:19:48 mounir: i don't want to assume all apis are only available for very signed apps 18:19:53 ... otherwise it's too constrictive 18:20:05 ... if you have a UC for it, but i don't see a reason 18:20:15 zkis: i have a revision id from this api 18:20:19 ... i fetch changes since then 18:20:24 ... if it isn't available, i get an error 18:20:28 ... and i fetch all again? 18:20:30 mounir: yes. 18:20:38 ... it's technically impossible to save all data 18:20:46 ... it seems like the only sane behavior 18:20:52 zkis: you have multiple applications 18:21:01 ... and you have to keep track of consumers? 18:21:02 mounir: no 18:21:12 ... the client keeps track of what it saw last 18:21:22 ... each application client will have the same datastore 18:21:31 ... and it saves the revision id it last tracked when it closes 18:21:46 ... and when it opens again, it checks that id against the current id 18:21:58 ... and then it can sync 18:22:07 ... you ca do it smoothly 18:22:13 ... implementations don't need to know every id 18:22:25 zkis: can you do predictive scrolling? 18:22:35 mounir: the developer could do UI that refreshes smoothly 18:22:40 q/ 18:22:40 zkis: this solves only Sync 18:22:44 q? 18:22:45 s|q/|| 18:22:57 mounir: if your messaging is searching name+number 18:23:06 ... you make your own indexedDB with indices on name+number 18:23:16 zkis: but, i fetch each one by one 18:23:23 mounir: no, you get it, and save it locally 18:23:37 zkis: so the data is duplicated N times (per application that uses a database) 18:23:39 kjwallis_ has joined #sysapps 18:23:47 mounir: this is the only way to solve the sync and indexing problem 18:23:57 zkis: so you make everyone do indexing? 18:23:59 q? 18:24:03 mounir: if they want to 18:24:05 ack genelian 18:24:18 genelian: question about Race conditions 18:24:28 ... suppose the central process has already removed a record 18:24:40 ... and client hasn't yet called getChanges() 18:24:41 q? 18:24:48 ... and the client thinks the record is still valid 18:24:51 q+ 18:25:03 ... what happens if the client calls update() or remove() and the record is no longer present? 18:25:13 mounir: i guess the Promise<> is rejected 18:25:22 genelian: the update/add will directly reject the operation? 18:25:25 mounir: not directly 18:25:35 ... if you have multiple clients trying to update 18:25:42 ... the central process will reject 18:25:56 genelian: the client app will get very confused 18:26:02 ... because it doesn't know the reason 18:26:14 mounir: it will get a change event 18:26:23 ... ah, you try to do something, not yet receive the change event 18:26:31 q? 18:26:31 ... but between your request and the fail, you'll get the change event 18:26:39 ... the change event comes from the same entity 18:26:43 ... so there should be order there 18:26:56 ... hopefully it should just work 18:27:11 genelian: this api seems to provide a very good way for synchronizing 18:27:18 ... and a fundamental api for dealing with a store 18:27:25 ... is it possible to replace the whole contacts api? 18:27:26 Josh_Soref: +1 18:27:35 genelian: or do we still need a partial api? 18:27:48 mounir: i think the contacts api would limit itself to describe the system store 18:27:54 ... there would be no more api for add/remove 18:28:01 genelian: sounds attactive 18:28:04 ack dsr 18:28:04 dsr, you wanted to ask about error handling on name clashes for data stores and to ask what Mozilla expects SysApps to do with the datastore proposal 18:28:07 ack dsr 18:28:07 dsr_, you wanted to ask about error handling on name clashes for data stores 18:28:35 dsr: provider provides datastore 18:28:37 ... consumer consumes 18:28:44 ... what if multiple applications provide the same name? 18:28:58 mounir: many applications can provide a store with a given name 18:29:20 ... this is there to allow "Skype", "Facebook", and another contacts app, and "Google", and the internal one from the phone 18:29:28 ... you call getDataStores("contacts") 18:29:46 ... this solves an issue where Intel wants Contacts API from multiple spaces 18:30:12 ... you have a GTalk 18:30:25 dsr: what do you expect us to do with this? 18:30:39 mounir: if the group is interested, we could start editing it, work on it, fix the details 18:30:44 ... it's really a prototype 18:30:59 ... we can use it to solve the problems from Contacts 18:31:28 dsr: just wondering if we have to extend the Charter 18:31:40 mounir: as i see it, it's there to solve Messaging and Contacts 18:31:45 ... but i guess there are legal issues 18:31:46 q? 18:31:49 ack zkis 18:32:03 zkis: last November, I think I had a Messaging API using a datastore of sicking's proposal 18:32:07 ... how would you actually use it 18:32:14 ... there were examples of SIM contacts 18:32:25 ... you might want to store things by datasource (sim1, sim2, ...) 18:32:40 ... i guess you can get rid of incoming events? 18:32:54 mounir: i don't know if you can get rid of incoming events, that would have to be discussed 18:33:19 zkis: datasources with different details/privacy 18:33:24 ... you might not see everything 18:34:01 mounir: for this, sim1/sim2/sim3, the owner would be {magic-string-for-system} 18:34:08 zkis: which property would specify sim1? 18:34:18 mounir: the object get(n)... 18:34:55 ... at any moment, if you want to know this you just work through your indexed database 18:35:25 mounir: the system database only contains stuff from the system 18:35:37 ... excluding Facebook, IRC, XMPP 18:35:51 zkis: in our case, that's the system 18:35:59 ... this is not right, SMS could be a web service 18:36:16 mounir: then that would be the SMS app on the phone, and its datastore for sendsms.example.com 18:36:30 zkis: i think we need a source property 18:36:56 [ cross talk about sim/system/messages ] 18:37:56 mounir: if i have Hangouts 18:37:58 kjwallis_ has joined #sysapps 18:38:03 ... even if it comes from the System 18:38:10 ... it's actually hangouts.google.com 18:38:22 zkis: is only things defined in SysApps system? 18:38:25 mounir: yes 18:39:03 zkis: if you don't allow the owner property to own use the property to distinguish the source 18:39:29 zkis: you're doing this based on an assumption that doesn't apply to all circumstances 18:39:32 q? 18:39:46 zkis: without understanding this, we can't say if we accept it 18:40:07 zkis: it's missing a field 18:40:10 mounir: that's intentional 18:41:07 mounir: i guess Intel isn't very enthusiastic about this api 18:41:15 ... i'd like group feedback on it 18:41:15 q+ 18:41:28 lgombos: i'm not sure what you're asking for feedback on 18:41:40 ... is the question "is this a good foundation for contacts+messaging" 18:41:49 ... or "a good spec in general" 18:42:09 mounir: this could live anywhere, unless it's needed to solve our problems 18:42:23 ... so, "does the group think this is a solution to try to solve contacts+messaging" 18:42:33 lgombos: i agree w/ zkis 18:42:47 ... we can't decide if we don't go through an exercise to see if it works 18:42:56 mounir: as Chair, should we as a group try to work on this 18:43:00 ... or should we discard it 18:43:11 ... and try to solve it independently for Messaging/Contacts 18:43:14 lgombos: it's a fairly good spec 18:43:24 ... we spent a lot of time trying to understand the proposal 18:43:26 s/good/new 18:43:39 ... but we should spend some time looking at what this solves 18:43:50 mounir: you're asking what this solves for Contacts/Messaging 18:43:55 ... it solves Syncing 18:44:10 ... it solves Multiple provider 18:44:13 q- 18:44:20 zkis: i think it solves things if we address datasource 18:44:26 marcosc: it solves the datasource issue 18:44:35 ... we don't need 100 apis to do things over and over 18:44:42 q+ 18:44:47 lgombos: it inherently makes Contacts/Messaging more aligned 18:44:58 mounir: it reduces Contacts/Messaging to defining a Store 18:45:12 ... no definition for Add(), Remove(), Find(), Filter() 18:45:19 ... Messaging still needs Send() 18:45:33 ... but we have to decide if it's a correct solution 18:45:37 lgombos: thanks for those 18:45:45 q? 18:45:48 ... i think we should continue and see how far we can go 18:45:56 marcosc: if i had an outside Mozilla hat on 18:46:01 ... i'd like to see if it works for us 18:46:12 ... i'm looking at it and going "it looks really interesting" 18:46:21 ... but i'd really like to see if it works for Firefox OS 18:46:27 anssik: which other apps? 18:46:40 marcosc: Contacts, Messaging, Call Logs, Calendar 18:46:52 ... a million cases that should have been covered by IndexedDB 18:46:57 ... but there's another dataprovider 18:47:23 mounir: if you want to do Call Logging 18:47:34 ... you could use this 18:47:45 anssik: you're very close to completion of the api? 18:47:50 mounir: i have to review patches 18:47:53 anssik: apps are done? 18:47:54 mounir: no 18:48:04 ... we're fairly close to pushing to mozilla-central 18:48:11 ... we have an app layer person experimenting with this 18:48:16 ... trying to test it in their own repo 18:48:21 ... i was hoping it'd be done earlier 18:48:53 +q 18:48:57 s/+q/q+/ 18:49:35 anssik: sounds like after this F2F you'll have feedback 18:49:55 mounir: mozilla might use gaia.mozilla.org 18:50:06 ... but there's no way to reach interoperability 18:50:18 ... if tizen wants to ship w/ some default providers 18:50:23 ... they'll have providers 18:50:30 ... Firefox will have Facebook installed by default 18:50:37 ... that app will have a Contacts app built in 18:50:45 ... it will be a .facebook.com origin 18:50:54 ... they don't have to rely on it being present 18:51:01 anssik: thanks 18:51:13 q? 18:51:36 anssik: you could make it more like a spec 18:51:50 ... zkis you could try to look at it 18:52:00 mounir: unless marcosc looks at it, i can't commit anyone 18:52:18 marcosc: this proposal impacts a bunch of specs in phase one 18:52:27 ... but it also reduces scope of a bunch of specs in phase one 18:52:46 ... that's why it's important on the mozilla side to provide feedback asap 18:52:51 ... and to address zkis 's concerns 18:52:57 ... if we get that, i'd be interested in contributing 18:53:03 q- 18:53:15 anssik: sounds like we'd want to push Contacts+Messaging to Phase 2 and replace them with this 18:53:25 marcosc: we no longer need them as DataSource 18:53:39 ... my biggest concern is Cursor etc 18:53:45 ack chris 18:53:45 ack chris 18:53:59 chris: i have some concerns about Contacts 18:54:02 ... when it comes to schema 18:54:06 ... how do you specify it? 18:54:13 marcosc: it would be specified in JS as objects 18:54:30 ... we have a non-normative thing in telephony 18:54:39 ... we have a contacts object in the spec already 18:54:55 mounir: we'd just reuse the contacts object from the contacts api 18:55:08 ... there it will be a JSONized thing 18:55:31 chris: there are several things this is trying to solve 18:55:36 ... which could be solved in Contacts as well 18:55:42 ... in Tizen, we have several sources 18:55:52 ... and there's an origin, and readonly... 18:56:02 q? 18:56:10 q- marcosc 18:56:43 marcosc: Mozilla should report back w/ Implementation experience to the group 18:56:47 +1 on marcosc 18:56:50 ... so the group can make an informed decision 18:56:55 q+ 18:57:31 mounir: zkis's concern is multiple origin from the system 18:57:38 ... which is not something we want to support 18:57:42 ... we won't fix that 18:57:48 zkis: i think having this api 18:57:51 ... is a good thing 18:57:58 ... i think i'd know how to use this 18:58:06 ... we could include it in the charter 18:58:15 ... but we'd need to address it 18:58:21 ... this could be done by issues 18:58:29 mounir: i don't believe this requires charter changes 18:58:40 ... this does what Contacts/Messaging were trying to do 18:58:43 ... IANAL 18:58:50 ... this is doing Syncing 18:58:56 ... which they were doing 18:59:02 s/doing/trying to do/ 18:59:13 dsr: it sounds like refactoring specifications 18:59:22 ... so if we don't hear any objections, we presume we can do this 18:59:35 ... are we putting DataStore into phase1 and Contacts into phase2? 18:59:44 mounir: on Thursday we'll consider new work items 18:59:50 ... i'm ok w/ moving Messaging to Phase 2 18:59:56 ... Contacts is a simple layer on the datastore 19:00:08 ... it seems to be better to have a simple api on top of Datastore to drive it 19:00:18 zkis: i think we should keep all the phase 1 items 19:00:21 ... this is a helper 19:00:31 mounir: i have no strong opinion, we should speak about it on Thursday 19:00:44 anssik: as long as we have resources to push forward 19:00:51 ... i think we can keep them active 19:01:00 ... if we have people to move them together in parallel, that's ok 19:01:04 mounir: +1 19:01:24 ... with DataStore, we're not adding more work 19:01:28 ... we're refactoring 19:01:36 q? 19:01:58 ack chris 19:02:07 chris: about revisionID in datastore 19:02:16 ... when you access it twice in a row, it might return different values? 19:02:40 mounir: yes 19:02:51 chris: why not make it a method? 19:03:15 mounir: in battery api, if you ask the battery level twice, you might get different values 19:03:20 ... there's a change event 19:03:44 chris: that id is an integer might be problematic 19:03:49 ... vCard uses an integer 19:03:55 mounir: that's an internal implementation of the store 19:03:58 s/store/storage/ 19:04:06 ... the vCard format would be the object 19:04:20 ... the datastore associates an id with a vCard object 19:04:30 ... the first id has nothing to do w/ the vCard object 19:04:57 chris: the datastore is a way to interact with a system backend? 19:05:17 chris: some contacts engines use a string id for their backend key 19:05:33 mounir: the id is just an autoincrement 19:05:48 ... if you have an internal id, you have an internal id in the contacts 19:05:58 ... if you want to expose gnome contacts, you'd integrate them 19:06:06 ... and have them add and find a way to synchronize 19:06:19 chris: in Tizen, we have a Contacts API 19:06:25 ... a web api in front of a Contacts backend 19:06:33 ... may/may-not be the same one as in Gnome 19:06:45 ... it doesn't seem like it's designed to expose a native backend 19:06:50 mounir: right 19:06:56 ... it's designed to expose a contacts-api backend 19:07:08 ... contacts api will define "some data" 19:07:18 ... if for some reason your system is using some other backend 19:07:26 ... you'll have to do the translation yourself 19:07:31 zkis: if you have a native interface 19:07:43 ... and want to expose sync 19:07:49 ... it's a shared database between applications 19:08:03 ... per application v. per runtime copies 19:08:08 mounir: i didn't copy 19:08:13 s/copy/follow/ 19:08:43 chris: a datastore might be a native backend 19:09:07 { 0: {vCardId: "10", name: "John Joe"} } 19:09:22 { 1: {vCardId: "12", name: "Jane Smith"} } 19:09:51 + lastModifiedFields on each 19:10:19 chris: why are you using a string key? 19:10:30 [ To have an Array backend ] 19:10:49 mounir: we're not trying to make implementations easy 19:10:55 ... we're trying to make consumers lives easy 19:11:06 ... there are a handful of implementations 19:11:10 ... millions of developers 19:11:18 ... i understand you need a layer between your native thing and your web thing 19:11:45 { 2: {vCardId: "15", name: "Eric Lapp", lastModified: 912870374 }} 19:12:04 chris: we'd need two hashtables between string ids and integers 19:12:09 ... it's annoying to implement 19:12:40 zkis: developers don't care if it's an integer or string 19:12:54 ... DataStore exists because the other was too slow 19:13:43 [ you maintain a lastModified for your store, and a max count, and a mapping of uuid to lastModified ] 19:14:02 [ if uuid isn't found, you fail early on getChanges() ] 19:14:36 [ if uuid is found, you can just return all objects which have lastModified > lookedupLastModifiedByUUID ] 19:15:16 q? 19:15:22 mounir: taking mozilla's wording, that mozilla should come back to the group w/ implementation feedback 19:15:29 dsr: do we need to clarify UCs? 19:15:33 mounir: yeah 19:15:44 ... this is a discussion we had about Messaging last time 19:15:49 ... iirc 19:16:06 ... zkis was for allowing opaque ids 19:16:11 ... there was a service thing 19:16:17 ... that was a simId 19:16:21 ... an int 0 19:16:29 ... you wanted it to be a string for xmpp:irc:.... 19:16:37 ... for telephony it was the same 19:16:43 ... using SIP client 19:16:53 ... generally speaking, trying to do apis like that doesn't reach interop 19:17:02 ... you'll get an app that checks the service id 19:17:08 ... and that magic string will only work for Tizen 19:17:20 ... you're using an api that's standardized in w3c 19:17:34 zkis: you can't say an id works in one place and anywhere else 19:17:46 mounir: once it's an opaque id, people can look at the id 19:17:52 ... the id starts as a magic id in Tizen 19:17:56 ... and someone will hard code it 19:18:06 ... and app will do something 19:18:15 ... this opaque string will be xmpp:1 19:18:24 ... you'll definitely have developers using strings 19:18:34 zkis: apps in tizen don't care about the format of the id 19:18:44 mounir: apps in tizen might not care 19:18:49 ... but third party apps will 19:18:57 zkis: but you don't care 19:19:27 Josh_Soref: we have experience with app authors sniffing UserAgent 19:19:33 mounir: you're saying the app will work on Tizen 19:19:37 ... but it won't work elsewhere 19:19:46 ... the idea is that if one implementation has the majority 19:19:55 zkis: we don't have this problem 19:20:07 ... there's no fragmentation 19:20:11 mounir: there will be fragmentation 19:20:47 anssik: mounir, you have UCs 19:20:51 ... you have them on your Wiki 19:21:44 anssik: what's the way forward? 19:21:54 zkis: take Contacts/Messaging and see how they work with this API 19:21:58 anssik: exactly 19:25:41 RESOLUTION: the group is going to work on Messaging, Telephony and Contacts on top of DataStore 19:25:52 [break] 19:32:07 s/marcosc/scribe/ 19:47:03 lgombos has joined #sysapps 19:48:14 Topic: Contacts API 19:49:12 mounir, pong 19:49:15 Zakim, who is on the phone? 19:49:15 On the phone I see [Mozilla], ??P1 19:49:16 [Mozilla] has dsr, anssik, marcos, mounir, spoussa, kwallis, zoltan, wonsuk, Josh_Soref, kenneth_, zkis, gmandyam, Dong-Young, Joonhyung, opoto, genelian, dsuwirya, lgombos, Claes, 19:49:16 ... hsinyi, Marta, jmajnert, Daniel, JonathanJ1 19:49:22 Zakim, ??P1 is chris 19:49:22 +chris; got it 19:49:53 http://contacts-manager-api.sysapps.org/ 19:50:30 chris: we changed to Promises 19:50:38 ... we added more Dictionaries 19:50:52 ... we no longer have contacts in everything as a dictionary 19:51:04 ... preferred is no longer a string, it's now a boolean 19:51:47 q+ 19:51:59 ack zkis 19:52:05 zkis: chris at the last F2F 19:52:10 ... we discussed contact sources? 19:52:20 wonsuk_ has joined #sysapps 19:53:05 ... could we have a way to access Facebook/Skype/etc. 19:53:16 chris: one possibility, but another is separate addressbooks 19:53:22 zkis: how do we access those datastores? 19:53:38 chris: with the current API, you could have getAddressBooks() and each has an origin 19:54:02 ... this is the pattern used in Tizen 19:54:19 ... in the root contact manager you can get a list of address books 19:54:25 zkis: i don't find that api 19:54:50 https://developer.tizen.org/help/index.jsp?topic=%2Forg.tizen.web.device.apireference%2Ftizen%2Fcontact.html 19:54:55 mounir: can that be translated into different Datasources with different owner (origin) if we switch? 19:55:22 yeah, but do we have multiple address books support in the W3C Contacts API? 19:55:29 chris: yes, this would solve the same problem 19:56:29 mounir: the owner would be the manifest uri 19:56:52 q+ 19:57:00 facebook => http://facebook.com/manifest.json 19:57:09 ack gmandyam 19:57:10 skype => http://skype.com/manifest.json 19:57:13 gmandyam: with a sim based contacts 19:57:18 ... you're talking to a Secure Element 19:57:44 ... when you enumerate the device 19:57:59 ... -- the datastore API makes the assumption that the contacts are already on the device 19:58:31 mounir: for Firefox OS, we have a sim api, with a sim toolkit and there's a get contacts 19:58:39 ... and from there you can save the contacts to the contacts in the device 19:58:43 ... you can't write contacts to the sim 19:58:48 ... we believe that's a UC from the 90s 19:58:54 ... even getting seems outdated 19:59:01 ... we think this is a sim api problem 19:59:07 ... not a contacts problem 19:59:20 zkis: what if you want to keep the contacts api separate 19:59:30 mounir: my opinion is that we should have a sim api 19:59:37 zkis: we have a messaging api 19:59:44 ... we wanted a datastore for sim 20:00:23 ... just as us have a messaging api doesn't prevent us from storing messages 20:00:35 ... we shouldn't be prevented from storing/exposing sim contacts 20:00:48 My point was that the typical mobile OS prompts the user upon enumeration of SIM contacts to store the info in device memory - DataStore API has no such ability. Mounir responded that such functionality could be in a SIM API. 20:00:51 mounir: the reason i don't seem contacts on the device as the same as contacts on device 20:00:59 ... as messages on sim as messages on device 20:01:12 ... you're limited with contacts 20:01:18 zkis: messages on the sim card 20:01:31 mounir: oh, sms on the sim card? i don't think we support that 20:01:37 zkis: we'd just need one more property 20:02:03 ... sim contacts, device facebook contacts 20:02:15 mounir: facebook UC is already solved by the owner attribute 20:02:22 zkis: if you solve FB, Skype, Google 20:02:27 ... that doesn't mean you solve the problem 20:02:36 mounir: SIM contacts are part of the system, but not part of the system for real 20:02:44 zkis: what's part of the system depends on the platform 20:03:04 mounir: to a user, contacts on the device are part of the device 20:03:17 ... on Android phone, you have Google Contacts and Device Contacts 20:03:26 zkis: the system thing is what messes up the whole idea 20:03:39 q? 20:03:39 mounir: owner... 20:03:45 zkis: then we have a bad api 20:04:29 marcosc: i was going to ask what's next w/ the contacts api 20:04:32 ... -> chris 20:04:51 chris: if i understood correctly, we wanted to see what it would look like w/ the datastore api 20:04:55 marcosc: correct 20:04:59 ... you're ok with doing it? 20:05:03 chris: i'm ok w/ trying it out 20:05:12 marcosc: that's all i was wondering 20:05:27 RRSAgent, draft minutes 20:05:27 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 20:05:33 marcosc has joined #sysapps 20:05:36 Topic: Messaging API 20:06:05 http://messaging.sysapps.org/ 20:06:07 i|Microphones arrive|Agenda: http://www.w3.org/wiki/System_Applications:_2nd_F2F_Meeting_Agenda| 20:06:35 s|http://messaging.sysapps.org/| -> http://messaging.sysapps.org/Messaging API| 20:06:45 q+ 20:06:48 zkis: the last changes to Messaging were changing to using promises 20:06:57 ... the issues are mostly editorial 20:07:01 ... except for 79 20:07:08 https://github.com/sysapps/messaging/issues/79 20:07:37 s|https://github.com/sysapps/messaging/issues/79 consider using MessagingService|-> https://github.com/sysapps/messaging/issues/79 consider using MessagingService objects| 20:07:45 -chris 20:07:54 zkis: one approach is to make things simple for people just trying to send messages 20:08:02 ... default service via defaultServiceId 20:08:14 ... if we used a serviceObject, then the methods would be on the service itself 20:08:23 ... and the service manager would just enumerate services 20:08:28 ... at the last F2F 20:08:35 ... mounir asked us to explorer this possibility 20:09:02 mounir: we spoke at Mozilla about having a default service 20:09:11 kjwallis has joined #sysapps 20:09:24 genelian: i don't think we have it 20:09:46 ... we haven't tried to deal w/ multiple sim cards yet 20:10:00 ... we do have a plan to be compatible w/ it 20:10:08 ... our plan is quite similar to this proposal 20:10:19 ... putting serviceId as a parameter of the send function 20:10:25 ... to control which sim card to use 20:11:08 genelian: i notice service related attributes 20:11:23 ... for added/removed 20:11:32 ... these things are also in the manager as well 20:11:42 ... can these three attributes be put into an up-later 20:11:46 s/later/layer 20:11:55 ... the messageManager which has both sms and mms 20:12:03 ... why not put the service related attributes on the manager? 20:12:18 zkis: we had it that way 20:12:29 ... but we were told to not have that much higherarchy 20:12:54 s/higherarchy/hierarchy/ 20:13:03 q? 20:13:09 marcosc: from a JS dev perspective, it's pretty bad that it's 20:13:16 navigator.messaging.sms.send() 20:13:53 zkis: service objects would make this better 20:13:56 marcosc: yes 20:14:05 ... or since they're static functions, putting them to smsmanager 20:14:21 zkis: so i can create a proposal by tomorrow 20:14:25 marcosc: yes 20:14:30 zkis: anything else? 20:15:31 genelian: we tried to delete 2000 messages 20:15:41 ... with ids, we had to call deleteById separately 20:15:45 ... and it took 30-40s 20:15:54 ... if we can provide an array of id's 20:15:57 ... it's better 20:15:59 zkis: i agree 20:16:06 ... this was also originally an array 20:16:46 ... this whole set of messages will change once messages integrate with Datastore 20:17:00 marcosc: it doesn't have delete(array[]), but we could add it 20:17:09 mounir: we can add it 20:17:16 genelian: it's worth adding 20:17:34 zkis: please create an issue 20:18:17 genelian: the array applies to deleteMessage/deleteConversation/markMessageRead/markConversationRead 20:18:53 zkis: does *Conversation still exist in Datastore? 20:19:03 Josh_Soref: probably not, since you'd be using *your* datastore instead of the main one 20:19:34 genelian: SmsManager.segmentInfo() 20:19:45 ... whenever users type in characters into the text 20:19:58 ... and something needs to enter text into the text 20:20:07 ... and the UI wants to update the segmentCount 20:20:11 ... or characters remaining 20:20:20 ... this function is a synchronous function 20:20:29 ... suppose we have text which is 5 characters 20:20:47 ... the App needs to call it 5 times, one for each character 20:20:53 ... this will block the process 20:20:57 ... and make the user feels bad 20:21:03 ... feeling the latency 20:21:12 Daniel_Samsung has joined #sysapps 20:21:13 ... i'd suggest to make this function async 20:22:15 mounir: making this async 20:22:19 ... you're typing in one process 20:22:28 ... and you have to go to another process to get segment info 20:22:34 ... you have ipc 20:22:44 ... i'm assuming segment info is related to the sim 20:23:28 mounir: can the JS do this math on its own or does it need something? 20:23:33 zkis: it needs something from the service 20:23:57 zkis: my opinion/understanding is that you can implement it in a sync manner 20:24:05 mounir: the service lives in another process 20:24:14 ... different from the app 20:24:24 ... we ask the service a question involving IPC 20:24:30 ... syncing the process 20:24:37 zkis: you should be able to cache that information 20:26:11 zkis: i suspect it's just math 20:26:25 ... but there could be an operator which has a service specific value 20:26:30 ... i'll need to check the specs 20:26:34 q+ 20:26:58 ack genelian 20:27:01 ack hsinyi 20:27:16 hsinyi: about the service project proposal 20:27:23 ... it looks like the very original one mozilla had 20:27:28 ... discussing w/ sicking 20:27:42 ... sicking suggested it's best to have a centralized sms received event 20:28:03 ... it isn't symmetric that we have received in one place and send in another 20:29:23 hsinyi: having one additional parameter to the sms api makes it easier 20:29:57 zkis: but if you try to send an sms with a stale token... 20:30:05 hsinyi: we have an api to get the services 20:30:10 ... but proposals work 20:30:16 ... but it's very hard to distinguish 20:30:26 zkis: i could create two specifications 20:30:32 ... it'd be nice to have sicking comment 20:30:57 zkis: hsinyi, please create issues about these things 20:31:08 q? 20:32:44 Topic: TPAC 20:33:07 dsr: TPAC, Shenzhen, China, 11-15 November 2013 20:33:19 ... could we do brainstorming on what topics? 20:33:25 anssik: is there overlap? 20:33:30 mounir: with WebApps 20:34:03 ... we scheduled to not overlap w/ DAP 20:34:12 ... but that resulted in overlapping w/ WebApps 20:34:25 dsr: would you like to see if i can make us not overlap w/ WebApps ? 20:34:29 mounir: that'd be good 20:35:23 dsr: Ian Jacobs sent an email to the chairs asking for info about what they'll cover @TPAC 20:35:29 mounir: we'll cover that on Thursday 20:36:28 topic: Test Suites 20:36:43 marcosc: we'll have to build test suites at some point 20:36:55 ... a lot of stuff happening @W3C wrt testing 20:37:08 ... we'll hear a lot about testing @TPAC 20:37:25 ... tobie langel went to w3c for a year on Testing the web platform 20:37:38 ... work has been done on centralizing the web platform test suites 20:38:06 ... at the w3c github 20:38:13 ... there's testthewebforward 20:38:15 ... testharness.js 20:38:41 -[Mozilla] 20:38:42 UW_SYSAPPS()8:00AM has ended 20:38:42 Attendees were dsr, anssik, marcos, mounir, spoussa, kwallis, zoltan, wonsuk, chris, Josh_Soref, kenneth_, zkis, gmandyam, Dong-Young, Joonhyung, opoto, genelian, dsuwirya, 20:38:42 ... lgombos, Claes, hsinyi, Marta, jmajnert, Daniel, JonathanJ1 20:39:14 ... testharness.js can automate most webidl testing 20:39:43 ... should we be allowed to go into LC/out of LC w/o a test suite 20:39:49 ... that's something we need to decide as a group 20:39:57 ... what role does testing play in our process as a WG? 20:40:02 ... we can't exit CR w/o a test suite 20:40:10 ... a lot of groups go into CR w/o a test suite 20:40:15 ... testing is how you verify your spec 20:40:26 ... going through line by line creating a test for every assertion 20:40:29 ... it's probably done @LC 20:40:40 ... a lot of the time, it's the editor who's writing the tests 20:40:43 test suite @ LC +1 20:40:55 ... in WebApps, there's a "Test Facilitator" who works on writing the test 20:41:15 mounir: it's better to have someone other than the editor writing the test 20:41:33 marcosc: it's tremendously difficult to get people to sign up for testing 20:41:42 ... so i'm thankful to Marta for signing up for app: 20:41:56 mounir: can we get a Test Facilitator? 20:42:04 ... maybe we can find a volunteer for the other specs 20:42:10 ... what do people think? 20:42:23 +1 20:42:24 marcosc: i'm in favor 20:43:00 Marta: i can do it, but not for every spec 20:43:28 https://github.com/sysapps/testsuites/tree/gh-pages/app-URI 20:43:33 marcosc: kenneth_, who writes the tests? 20:43:47 kenneth_: webkit commiters write tests when they write the patch 20:43:52 ... and tests for regression fixing 20:44:04 marcosc: we'll get some tests organically 20:44:08 Marta, thanks 20:44:19 mounir: there's a huge gap between implementation and tests going to w3c 20:44:23 kenneth_: np 20:44:39 ... we're trying to have someone dedicated to send tests to w3c 20:44:54 ... i think having someone dedicated to making sure we have tests for every spec would be good 20:45:25 mounir: which tests would you be interested in doing? 20:45:33 marcosc: task scheduler and possibly raw sockets 20:45:39 mounir: telephony? 20:46:38 Marta: App URI and Task Scheduler 20:48:19 RESOLUTION: the group is going to have a test facilitator for every spec 20:48:32 RESOLUTION: the specifications should have test being worked on starting LC, needed to go to CR 20:48:49 RESOLUTION: marcosc is test facilitator for raw sockets 20:49:01 RESOLUTION: Marta is test facilitator for app uri scheme 20:49:14 RESOLUTION: marcosc and Marta are test facilitators for task scheduler 20:49:20 lgombos: i understand w3c is trying to harmonize testing 20:49:22 ... that's great 20:49:28 ... but that's basically for "drive by web" 20:49:31 ... i don't know... 20:49:37 ... we might need different things for sysapp testing 20:49:43 marcosc: tobie says it isn't 20:49:54 ... we're supposed to get this for him too 20:50:12 lgombos: so we still need to write sysapps 20:50:17 mounir: i had a meeting w/ tobie 20:50:22 ... about testing for messaging 20:50:31 ... w/ testharness, we can only test the surface 20:50:40 ... for messaging, do we want to test that an sms has been sent and received? 20:50:51 you can have both levels 20:51:55 Josh_Soref: you could use GVoice and similar to receive SMS and check via http/imap/whatever 20:52:01 mounir: we could also use web driver 20:52:38 marcosc: when you go to CR, the Director looks at the Test Suite 20:52:53 ... so we need something solid 20:53:12 Topic: End 20:53:24 mounir: let's call it a day, and we'll start tomorrow @9am 20:53:26 [ adjourned ] 20:53:30 Marta has left #sysapps 20:53:33 RRSAgent, make minutes 20:53:33 I have made the request to generate http://www.w3.org/2013/08/27-sysapps-minutes.html timeless 20:53:38 RRSAgent, bye 20:53:38 I see 10 open action items saved in http://www.w3.org/2013/08/27-sysapps-actions.rdf : 20:53:38 ACTION: file a bug about maybe relaxing dependency on sniff [1] 20:53:38 recorded in http://www.w3.org/2013/08/27-sysapps-irc#T13-45-30 20:53:38 ACTION: make it clearer that uuid is not a hard requirement [2] 20:53:38 recorded in http://www.w3.org/2013/08/27-sysapps-irc#T13-45-48 20:53:38 ACTION: contact Google to see if they would be interested to implement this specification [3] 20:53:38 recorded in http://www.w3.org/2013/08/27-sysapps-irc#T13-55-25-2 20:53:38 ACTION: change the Task Scheduler spec to no longer have tz information [4] 20:53:38 recorded in http://www.w3.org/2013/08/27-sysapps-irc#T14-41-34 20:53:38 ACTION: chris should open an issue so we keep in mind the relation between Task Scheduler and Event Pages [5] 20:53:38 recorded in http://www.w3.org/2013/08/27-sysapps-irc#T14-46-31 20:53:38 ACTION: chris should file a bug about the race condition [6] 20:53:38 recorded in http://www.w3.org/2013/08/27-sysapps-irc#T14-53-38 20:53:38 ACTION: make clear that a missed alarm should be fired [7] 20:53:38 recorded in http://www.w3.org/2013/08/27-sysapps-irc#T15-33-44 20:53:38 ACTION: precise the precision ;) [8] 20:53:38 recorded in http://www.w3.org/2013/08/27-sysapps-irc#T15-35-29 20:53:38 ACTION: make an implementation reference [9] 20:53:38 recorded in http://www.w3.org/2013/08/27-sysapps-irc#T16-04-46 20:53:38 ACTION: file an issue for Raw Sockets renaming [10] 20:53:38 recorded in http://www.w3.org/2013/08/27-sysapps-irc#T16-21-11 20:53:53 Marta has joined #sysapps 20:54:01 jmajnert has left #sysapps