IRC log of dap on 2012-11-01

Timestamps are in UTC.

07:36:01 [RRSAgent]
RRSAgent has joined #dap
07:36:01 [RRSAgent]
logging to http://www.w3.org/2012/11/01-dap-irc
07:36:03 [trackbot]
RRSAgent, make logs world
07:36:03 [Zakim]
Zakim has joined #dap
07:36:05 [trackbot]
Zakim, this will be DAP
07:36:06 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
07:36:06 [trackbot]
Meeting: Device APIs Working Group Teleconference
07:36:06 [trackbot]
Date: 01 November 2012
07:36:12 [tomoyuki]
tomoyuki has joined #dap
07:37:16 [AnssiK]
AnssiK has joined #dap
07:37:34 [jsoh]
jsoh has joined #dap
07:37:36 [tpacbot]
tpacbot has joined #dap
07:40:01 [Yoshihiro]
Yoshihiro has joined #dap
07:41:05 [jgiraud]
jgiraud has joined #dap
07:41:17 [jgiraud]
present+ jerome_giraud
07:41:29 [Hidetoshi]
Hidetoshi has joined #dap
07:42:13 [fjh]
Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France
07:42:25 [fjh]
Chair: Frederick_Hirsch
07:42:40 [AnssiK]
Present+ Anssi_Kostiainen
07:42:48 [fjh]
Present+ Frederick_Hirsch
07:43:50 [shunan]
shunan has joined #dap
07:43:50 [Takahiro]
Takahiro has joined #dap
07:43:59 [Takahiro]
Takahiro has left #dap
07:45:30 [Yoshihiro]
Yoshihiro has joined #dap
07:45:36 [bjkim]
bjkim has joined #dap
07:47:11 [noriya_]
noriya_ has joined #DAP
07:47:45 [Sylvain_Lalande]
Sylvain_Lalande has joined #dap
07:48:16 [a12u]
a12u has joined #dap
07:49:53 [glenn]
glenn has joined #dap
07:53:04 [fjh]
Topic: Administrative
07:53:36 [bryan]
bryan has joined #dap
07:53:46 [kensaku]
kensaku has joined #dap
07:53:54 [nwidell]
nwidell has joined #dap
07:53:54 [dom]
trackbot, RRSAgent
07:53:54 [trackbot]
Sorry, dom, I don't understand 'trackbot, RRSAgent'. Please refer to http://www.w3.org/2005/06/tracker/irc for help.
07:53:59 [bryan]
present+ Bryan_Sullivan
07:54:01 [dom]
trackbot, start meeting
07:54:03 [trackbot]
RRSAgent, make logs world
07:54:05 [trackbot]
Zakim, this will be DAP
07:54:05 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
07:54:06 [trackbot]
Meeting: Device APIs Working Group Teleconference
07:54:06 [trackbot]
Date: 01 November 2012
07:54:08 [bryan]
scribenick bryan
07:54:12 [Shinji]
Shinji has joined #dap
07:54:13 [shoko]
shoko has joined #dap
07:54:13 [robint]
robint has joined #dap
07:54:16 [dom]
scribenick: bryan
07:54:21 [sakkuru]
sakkuru has joined #dap
07:54:22 [Milan_Patel]
Milan_Patel has joined #dap
07:54:22 [dom]
s/Teleconference/F2F
07:54:33 [bryan]
fjh: welcome and logistics
07:54:39 [comus]
comus has joined #dap
07:54:39 [Yoshiharu]
Yoshiharu has joined #dap
07:54:44 [bryan]
fjh: intros
07:54:48 [gmandyam]
gmandyam has joined #dap
07:54:49 [kenji]
kenji has joined #dap
07:54:56 [Claes]
Claes has joined #dap
07:55:03 [dom]
Present+ Dominique_Hazael-Massieux
07:55:06 [dnkim]
dnkim has joined #DAP
07:55:07 [Claes]
Present+ Claes_Nilsson
07:55:07 [shan]
Present+ Soonbo_Han
07:55:23 [fjh]
hi I'm chairing, from Nokia, Frederick Hirsch
07:55:23 [Yoshiharu]
Present+ Yoshiharu_Dewa
07:55:28 [comus]
Present+ Geun-Hyung KIm
07:55:29 [sato]
sato has joined #dap
07:55:41 [eduardo_fullea]
eduardo_fullea has joined #dap
07:55:43 [bryan]
anssik: from nokia, editing a bunch of specs, been out for a while and will catch up
07:55:48 [jsoh]
Present+ Jong Soo Oh
07:56:09 [hyun]
hyun has joined #dap
07:56:18 [jsoh]
Present+ JongSoo_Oh
07:56:18 [bryan]
bryan: from AT&T, not editing
07:56:21 [jiro]
jiro has joined #dap
07:56:26 [skim]
skim has joined #dap
07:57:02 [bryan]
jcdufourd:
07:57:09 [giuseppe]
giuseppe has joined #dap
07:57:09 [bryan]
Dom: back
07:57:18 [bryan]
Eduardo: from Telefonica
07:57:30 [bryan]
Jungkee: editing Pick Media etc
07:57:36 [youenn]
youenn has joined #dap
07:57:43 [eduardo_fullea]
Present+ Eduardo_Fullea
07:57:47 [bryan]
Claes: from Sony, editing
07:57:56 [jgiraud]
jerome giraud: orange
07:58:00 [bryan]
(missing most of them...)
07:58:12 [adambe]
adambe has joined #dap
07:58:23 [kensaku]
kensaku
07:58:51 [bryan]
aaa: Toshiba
07:58:53 [sato]
sato from Sony
07:58:59 [Takahiro]
Takahiro has joined #dap
07:59:00 [bryan]
bbb: from Sony
07:59:05 [kensaku]
kensaku from NTT communications
07:59:10 [bryan]
ccc: also from Sony
07:59:18 [jcdufourd]
jcdufourd has joined #dap
07:59:25 [shan]
Soonbo Han, LGE
07:59:26 [bryan]
soonbo: from LG, interested in Web Intents
07:59:35 [Yoshiharu]
s/ccc:/Yoshiharu Dewa:/
07:59:37 [bryan]
ddd: also from LG
07:59:40 [jsoh]
JongSoo_Oh, LGE
07:59:41 [bryan]
eee: also from LG
07:59:49 [bryan]
fff: from KDDI
07:59:50 [Jungkee]
Jungkee has joined #dap
07:59:55 [Jungkee]
Present+ Jungkee_Song
07:59:57 [giuseppe]
present+ giuseppe
07:59:59 [bryan]
guiseppe: from Opera
08:00:11 [giuseppe]
s/guiseppe/giuseppe/
08:00:15 [Yoshiharu]
s/bbb:/sato/
08:00:17 [bryan]
ggg: from Google, WebRTC chair, observer
08:00:28 [dom]
s/ggg/Harald_Alvestrand/
08:00:31 [bryan]
hhh: (missed all that)
08:00:37 [dnkim]
Donyun_Kim, LG Electronics
08:00:45 [bryan]
iii: from ETRI
08:00:51 [skim]
Sung Hei Kim from ETRI
08:00:51 [bryan]
jjj: also from ETRI
08:00:59 [comus]
<geunhyung> geunhyung from Mobile Web Forum
08:01:09 [Hidetoshi]
fff->Hidetoshi Yokota from KDDI
08:01:12 [gmandyam]
Giri Mandyam, from Qualcomm Innovation Center
08:01:12 [bryan]
kkk: from (.. Korea)
08:01:13 [hyun]
s/jjj/wook hyun/
08:01:19 [bryan]
giri: from QiC, member
08:01:20 [tomoyuki]
tomoyuki has joined #dap
08:01:20 [sato]
Present+ sato
08:01:21 [Jungkee]
Jungkee Song, Samsung Electronics, working on Pick-*-Intent in the group
08:01:26 [nwidell]
nwidell, Niklas Widell, from Ericsson AB
08:01:36 [bryan]
Niklas: from Ericsson
08:01:45 [youenn]
youenn fablet, observer, interested in Web Intent and service discovery
08:01:49 [Milan_Patel]
Milan Patel, Huawei
08:01:59 [bryan]
(missed the gentlemen before and after Niklas)
08:02:00 [shan]
s/soonbo:/shan: Soonbo Han/
08:02:11 [hyun]
s/kkk/shingak kang/
08:02:16 [bryan]
(observers)
08:02:22 [mounir]
mounir, Mozilla
08:02:28 [mounir]
Present+ Mounir_Lamouri
08:02:45 [noriya_]
Present+ noriya sakamoto from toshiba
08:02:57 [nwidell]
Present+ Niklas_Widell
08:03:29 [darobin]
darobin has joined #dap
08:05:08 [bryan]
fjh: agenda
08:06:00 [hta]
hta has joined #dap
08:06:01 [dom]
Topic: Agenda Review
08:06:10 [JonathanJ1]
JonathanJ1 has joined #DAP
08:06:21 [richt]
richt has joined #dap
08:06:37 [fwtnb_]
fwtnb_ has joined #dap
08:06:41 [tomoyuki]
Present+ Tomoyuki_Shimizu
08:06:48 [bryan]
... goal is to advance the specs, these first are in good shape
08:06:52 [dom]
-> http://www.w3.org/2009/dap/ DAP WG home page
08:07:03 [richt_]
richt_ has joined #dap
08:07:11 [bryan]
... battery spec is in cr, when to goto rec and get testing started is the question
08:07:33 [bryan]
... ambient light and proximity seem stable, the question is whether we can get to last call
08:07:46 [seo]
seo has joined #dap
08:07:55 [richt_]
Present+ Rich_Tibbett
08:07:55 [daniel_samsung]
daniel_samsung has joined #dap
08:08:03 [kotakagi]
kotakagi has joined #dap
08:08:12 [bryan]
... vibration is in cr, need to assess test case status and when we can progress it
08:08:28 [bryan]
... in summary to figure out roadmap for specs in good shape
08:08:40 [bryan]
... may also talk about network info api (maybe shelved)
08:09:09 [bryan]
... also privacy in general, in principle, christine sharing the privacy group may join us
08:09:35 [bryan]
... we kind of pushed the earlier work aside and focused on data minimization, but need to consider revisiting
08:09:44 [adrianba]
adrianba has joined #dap
08:09:49 [bryan]
... we may take longer breaks for discussions
08:10:12 [bryan]
... after break html media capture, in LC and stable but has some comments recently
08:10:37 [bryan]
... we got lc comments, and some responses were not accepted. we need to resolve all today to proceed to LC
08:10:56 [bryan]
... after lunch, web intents all afternoon
08:11:41 [bryan]
... need to review webapps discussion, and discuss status and implementations, issues etc from google
08:12:01 [Wonsuk]
Wonsuk has joined #dap
08:12:20 [bryan]
... mounir also is here and we need to take these two pieces of work forward
08:12:25 [tomoyuki]
Present- Tomoyuki_Shimizu
08:12:27 [JonathanJ1]
Present+ Jonathan_Jeon
08:12:28 [bryan]
... tomorrow we will start at nine
08:12:30 [Wonsuk]
Present+ Wonsuk_Lee
08:12:57 [bryan]
... tomorrow on the specs built upon web intents, including calendar to get it moving again
08:13:12 [npdoty]
npdoty has joined #dap
08:13:31 [bryan]
... then claes's work on web intents addendum. cathy is not here (Sandy) but we need to discuss the comments
08:13:50 [bryan]
claes: there were breakout sessions and will share results
08:14:12 [sakkuru]
sakkuru has joined #dap
08:14:13 [bryan]
fjh: after lunch richt's network service discovery draft
08:14:23 [Josh_Soref]
Josh_Soref has joined #dap
08:14:23 [seo]
seo has joined #dap
08:14:29 [bryan]
... somewhere about media capture and streams
08:14:33 [whyun]
whyun has joined #dap
08:14:45 [bryan]
... hopefully travis will be here to talk about tracks
08:15:07 [bryan]
... then something about billboards, (digital signage)
08:15:44 [bryan]
... maybe talking about coremob what to do with them
08:15:56 [bryan]
... on interop, a lot of work being done on testing and tools
08:16:15 [bryan]
... been working on the actions and not much to do there
08:16:25 [bryan]
... rough outline so far, anything else?
08:16:35 [AnssiK]
q?
08:16:35 [dom]
q?
08:17:02 [dom]
Topic: Minutes approval
08:17:09 [bryan]
... any objection to approving the minutes
08:17:18 [Josh_Soref]
RRSAgent, draft minutes
08:17:18 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:17:34 [Josh_Soref]
RRSAgent, make logs public
08:17:35 [Josh_Soref]
RRSAgent, draft minutes
08:17:35 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:17:46 [bryan]
proposed RESOLUTION: Minutes from 3 October 2012 are approved.
08:17:48 [Josh_Soref]
s/trackbot, RRSAgent//
08:17:55 [bryan]
RESOLUTION: Minutes from 3 October 2012 are approved.
08:17:55 [Josh_Soref]
s|Sorry, dom, I don't understand 'trackbot, RRSAgent'. Please refer to http://www.w3.org/2005/06/tracker/irc for help.||
08:18:01 [Josh_Soref]
s/scribenick bryan//
08:18:04 [bryan]
bryan: what about sysapps
08:18:38 [bryan]
... would like to talk about synergy
08:18:38 [Josh_Soref]
s/Yoshiharu Dewa:/Yoshiharu_Dewa:/
08:18:51 [Josh_Soref]
s/wook hyun:/wook_hyun:/
08:18:59 [fjh]
http://lists.w3.org/Archives/Public/public-device-apis/2012Oct/att-0014/minutes-2012-10-03.html
08:19:01 [Josh_Soref]
s/shingak kang:/shingak_kang:/
08:19:07 [dom]
Topic: Relationships with SysApps WG
08:19:15 [Josh_Soref]
s/giri:/gmandyam:/
08:19:18 [Josh_Soref]
RRSAgent, draft minutes
08:19:18 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:19:29 [Josh_Soref]
s/Niklas:/Claes:/
08:20:11 [Josh_Soref]
s/sato from Sony/sato: Sato, Sony/
08:20:13 [Josh_Soref]
s/sato from Sony//
08:20:34 [Yuan]
Yuan has joined #dap
08:20:39 [fjh]
bryan: would like to have synergy with DAP, and share common privacy approaches for example
08:20:39 [Josh_Soref]
s/Yoshiharu_Dewa:/Yoshiharu_Dewa: Yoshiharu Dewa, Sony/
08:20:49 [fjh]
bryan: would like to look at privacy more closely
08:21:07 [fjh]
dom: how can we be concrete on this
08:21:16 [Josh_Soref]
s/giuseppe:/giuseppe: Giuseppe Pascale/
08:21:18 [sunghan]
sunghan has joined #dap
08:21:27 [fjh]
bryan: might consider extending existing DAP interfaces in sysapps
08:21:37 [Josh_Soref]
s/Harald_Alvestrand: from Google/Harald_Alvestrand: Harald Alvestrand, Google/
08:22:10 [fjh]
richt: if it can run in the browser context it should be defined in DAP
08:22:24 [Josh_Soref]
s/fff: from KDDI/Hidetoshi: Hidetoshi Yokota from KDDI/
08:22:35 [Josh_Soref]
s/fff->Hidetoshi Yokota from KDDI//
08:22:46 [fjh]
overlap of dap and sysapps is about five people
08:22:57 [fjh]
at least hands raised in the room
08:23:33 [bryan]
jcdofourd: some apis picked up in sysapps have been shelved in this group, it should not be forbidden in another
08:24:02 [bryan]
fjh: we need to be productive, and ensure that browser context use is in the specs that browser vendors will implement
08:24:08 [Josh_Soref]
s/Claes: from Sony, editing/nwidell: Niklas Widell from Sony, editing/
08:24:17 [bryan]
... maybe it would make sense to see how it plays out, but not get into it deep now
08:24:32 [Josh_Soref]
RRSAgent, draft minutes
08:24:32 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:24:47 [bryan]
jcdofourd: execution and security model is a worse overlap, a meta-level for interfaces
08:24:50 [dom]
-> https://www.w3.org/2000/09/dbwg/overlap?ids[43696]=on&ids[58119]=on Overlap of formal participants between DAP and SysApps WG
08:25:06 [bryan]
... how things should work around security
08:25:07 [waynecarr]
waynecarr has joined #dap
08:25:17 [bryan]
fjh: in other words we should look at it
08:25:18 [waynecarr]
waynecarr has left #dap
08:25:34 [bryan]
... there was a contribution in sysapps
08:25:45 [Josh_Soref]
s/nwidell: Niklas Widell from Sony, editing/Claes: Claes Nilsson from Sony, editing/
08:25:54 [bryan]
jcdufourd: (there are some proposals)
08:26:18 [fjh]
ISSUE: should DAP review and take advantage of SysApps security models
08:26:18 [trackbot]
Created ISSUE-126 - Should DAP review and take advantage of SysApps security models ; please complete additional details at http://www.w3.org/2009/dap/track/issues/126/edit .
08:26:32 [Josh_Soref]
s/Claes: from Ericsson/nwidell: Niklas Widell, from Ericsson/
08:26:37 [nwidell]
q+
08:26:43 [Josh_Soref]
RRSAgent, draft minutes
08:26:43 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:26:44 [Kangchan]
Kangchan has joined #dap
08:26:45 [tpacbot]
tpacbot has joined #dap
08:26:52 [bryan]
fjh: concerned about two working groups with different IPR etc not sure what we can do here
08:26:57 [dom]
ack nwidell
08:27:30 [tomoyuki]
tomoyuki has joined #dap
08:27:31 [bryan]
nwidell: when the charter was discussed, the sysapps APIs were intended to have a flexible security model
08:27:31 [dom]
-> http://www.w3.org/2012/09/sysapps-wg-charter SysApps WG charter
08:27:51 [bryan]
topic: battery api
08:27:54 [skang5]
skang5 has joined #dap
08:28:06 [bryan]
anssik:
08:28:29 [bryan]
anssik: brief overview of battery status api
08:28:51 [Josh_Soref]
s/jcdufourd:/jcdufourd: Xjcdufourd/
08:28:54 [Josh_Soref]
RRSAgent, draft minutes
08:28:54 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:29:09 [bryan]
anssik: various features exposed for implementation in browsers and web-based os's... works in both world
08:29:23 [Josh_Soref]
s/jcdufourd: Xjcdufourd/jcdufourXd: Xjcdufourd/
08:29:24 [richt_]
q+
08:29:27 [Josh_Soref]
s/jcdufourd:/jcdufourd: Xjcdufourd/
08:29:33 [bryan]
anssik: sitting in cr for a while. no CRs since then, so the spec is considered stable
08:29:42 [Josh_Soref]
s/jcdufourXd: jcdufourd/jcdufourd: /
08:29:43 [richt]
q?
08:29:46 [Josh_Soref]
RRSAgent, draft minutes
08:29:46 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:29:50 [spoussa]
spoussa has joined #dap
08:29:54 [bryan]
anssik: currently a stable version in firefox nightly
08:30:12 [Milan_Patel]
Milan_Patel has joined #dap
08:30:13 [bryan]
anssik: backends are available for windows
08:30:17 [Josh_Soref]
s|s/jcdufourXd: jcdufourd/jcdufourd: /||
08:30:26 [Josh_Soref]
s/jcdufourXd: Xjcdufourd/jcdufourd: /
08:30:28 [dom]
-> http://w3c-test.org/dap/battery/tests/ Battery API test suites
08:30:29 [Josh_Soref]
RRSAgent, draft minutes
08:30:29 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:30:35 [bryan]
anssik: been working on a test suite, just run the suite and provide feedback
08:30:36 [dom]
s/suites/suite
08:30:53 [bryan]
... it's a bit tricky since automated tests are not possible or easy
08:31:06 [bryan]
... part of the tests address interfaces and others are manual tests
08:31:15 [dom]
q+ to ask about (other) implementation plans, idlharness
08:31:16 [bryan]
... results are manually validated
08:31:17 [Josh_Soref]
s/Xjcdufourd/Jean-Claude Dufourd/
08:31:22 [Josh_Soref]
RRSAgent, draft minutes
08:31:22 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:31:29 [dom]
q+ to ask about testing methodology in DAP general
08:31:34 [bryan]
... next steps after validation of the suites, moving to PR
08:31:40 [spoussa]
Present+ Sakari_Poussa
08:31:52 [fjh]
ack richt
08:31:57 [SKim]
SKim has joined #dap
08:32:07 [Josh_Soref]
s/Dom: back/dom: Dominique Hazael-Massieux, w3/
08:32:16 [bryan]
richt: we dont have to rush to PR
08:32:27 [bryan]
... what were the implementations so far?
08:32:54 [bryan]
anssi: firefox (browser and OS), tizen 2.0
08:32:57 [dom]
-> http://www.w3.org/2009/dap/wiki/ImplementationStatus#Battery_Status_API Implementation status of battery API
08:33:05 [Josh_Soref]
s/Present+ noriya sakamoto from toshiba/Present+ Noriya_Sakamoto/
08:33:06 [bryan]
richt: has this seen any adoption and interesting use cases?
08:33:28 [Josh_Soref]
s/Present+ Geun-Hyung KIm/Present+ Geun-Hyung_KIm/
08:33:30 [bryan]
anssik: developers seem excited at conferences
08:33:37 [Josh_Soref]
s/Present+ Jong Soo Oh/Present+ Jong_Soo_Oh/
08:33:54 [bryan]
... when you combine this with some other APIs more cool stuff is expected
08:33:54 [AnssiK]
* spec in CR since May 2012: http://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html
08:33:58 [Josh_Soref]
RRSAgent, draft minutes
08:33:58 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:34:06 [AnssiK]
* no normative changes since CR, spec changelog: http://dvcs.w3.org/hg/dap/log/tip/battery/Overview.html
08:34:10 [Josh_Soref]
present+ Josh_Soref
08:34:15 [bryan]
fjh: we need to ensure its done right and do not want to rush, but move forward
08:34:20 [AnssiK]
* implementation status: Firefox (Nightly), Firefox OS, some WebKit ports (such as EFLWebKit): http://www.w3.org/2009/dap/wiki/ImplementationStatus#Battery_Status_API
08:34:26 [bryan]
richt: the objective is lots of implementations, not just a spec
08:34:34 [AnssiK]
* try it on Firefox Nightly (will ship in Firefox 18 unprefixed?): http://nightly.mozilla.org/
08:34:42 [Josh_Soref]
s/Donyun_Kim/Donyun Kim/
08:34:45 [AnssiK]
* test suite, reviews appreciated: http://w3c-test.org/dap/battery/tests/submissions/anssik/
08:34:46 [Josh_Soref]
present+ Donyun_Kim
08:34:50 [AnssiK]
* battery-interface.html is the only fully automated test, others are functional tests
08:34:53 [bryan]
... we have hints that clarifications may be needed, maybe leave in CR for a couple or years as we work them out
08:34:54 [fjh]
q?
08:34:55 [AnssiK]
* next: move to PR?
08:34:57 [fjh]
ack dom
08:34:57 [Zakim]
dom, you wanted to ask about (other) implementation plans, idlharness and to ask about testing methodology in DAP general
08:34:59 [bryan]
fjh: not sure that is a good idea
08:35:08 [AnssiK]
[that was an outline of my talk]
08:35:17 [gmandyam]
+q
08:35:28 [bryan]
dom: so to recap, just mozilla as a browser today. not sure we should move to CR with just one browser implementing
08:35:32 [Josh_Soref]
s/Present+ sato/Present+ Naoyuki_Sato/
08:35:37 [fjh]
s/CR/PR/
08:35:42 [bryan]
... any comments from the room?
08:35:47 [Takahiro]
Takahiro has joined #dap
08:35:58 [Josh_Soref]
present+ Sylvain_Lalande
08:36:14 [fjh]
i agree with Dom, but some work that doesn't progress stays indefinitely in CR we do not want to end up in that state.
08:36:27 [bryan]
mounir: its in firefox 16
08:36:42 [bryan]
anssik: will try to provide a live demo
08:37:10 [bryan]
richt: at a design level, its good and on the roadmap with other sensors, competing with other work
08:37:24 [bryan]
... we agree with the approach and the design though
08:38:08 [bryan]
dom: any other implementation plans to share
08:38:31 [bryan]
yungkee: implementation in tizen is complete
08:38:39 [Josh_Soref]
present+ Kensaku_Komatsu
08:38:59 [Josh_Soref]
s/kensaku from/Kensaku Komatsu from/
08:39:19 [bryan]
fjh: answer is firefox and tizen implementations so far
08:39:27 [Josh_Soref]
s/kensaku/X_X_X
08:39:28 [bryan]
dom: tizen is not a browser
08:39:56 [Josh_Soref]
RRSAgent, draft minutes
08:39:56 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:39:58 [bryan]
anssik: firefox OS and browser are different too
08:40:15 [Josh_Soref]
s/kensaku//
08:40:22 [bryan]
dom: important to stick to browsers as the goal for implementations
08:40:24 [Josh_Soref]
s/X_X_X/kensaku/
08:40:29 [Josh_Soref]
RRSAgent, draft minutes
08:40:29 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:40:38 [bryan]
anssik: how much platform-specific code is in tizen?
08:40:55 [bryan]
yungkee: will follow up to see what can be shared
08:41:14 [robint]
robint has joined #dap
08:41:25 [bryan]
wonsuk: heard about a blackberry implementation
08:41:40 [fjh]
s/yungkee/jungkee/
08:42:32 [bryan]
anssik: (shows a demo of tests)
08:42:35 [Josh_Soref]
s/kensaku/scribe/
08:42:51 [Josh_Soref]
RRSAgent, draft minutes
08:42:51 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:43:02 [bryan]
... just looking at the interface as specified, easy stuff
08:43:08 [Josh_Soref]
s/Kensaku Komatsu/kensaku: Kensaku Komatsu/
08:43:10 [Josh_Soref]
RRSAgent, draft minutes
08:43:10 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:43:24 [dom]
q+ to mention idlharnes
08:43:53 [Josh_Soref]
s/dnkim/scribe/
08:43:55 [Josh_Soref]
s/Donyun Kim/dnkim: Donyun Kim/
08:44:33 [bryan]
... (runs a discharging tests) the test calculates primes, shows that the battery is being eaten up by both CPU cores being used for the calculation
08:44:58 [Josh_Soref]
s/skim/scribe/
08:45:11 [Josh_Soref]
s/Sung Hei Kim/SKim: Sung Hei Kim/
08:45:13 [bryan]
... calculation is in the web worker, waiting for the discharging time to update... this shows how testing this type of API can be challenging
08:45:33 [bryan]
... maybe webdriver could help, so to emulate some operations
08:45:54 [bryan]
... the test was passed
08:46:14 [bryan]
... after running you have to validate by checking the system battery against what was reported
08:46:31 [Josh_Soref]
s/jsoh/scribe/
08:46:40 [Josh_Soref]
s/JongSoo_Oh, LGE/jsoh: JongSoo_Oh, LGE/
08:46:44 [Josh_Soref]
RRSAgent, draft minutes
08:46:44 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
08:46:49 [bryan]
... if the test fails, how to prompt the user needs to be figured out. for now there appears to be a bug in the implementation
08:47:13 [dom]
q?
08:47:19 [bryan]
... deciding when to prompt the user is tricky
08:47:29 [bryan]
richt: probably should not mark as passed
08:47:38 [GregBillock]
GregBillock has joined #dap
08:47:57 [bryan]
anssik: got the language from the css reftests, to prompt the user on what is expected
08:48:18 [Josh_Soref]
present+ Jean-Claude_Dufourd
08:48:22 [bryan]
richt: in css tests you have visual feedback and also programmatic checking
08:48:42 [bryan]
dom: not sure the harness has this yet, but in this case it's a pass but check result
08:49:00 [bryan]
... someone needs to bring the idea to the public testing list
08:49:05 [Josh_Soref]
s/youenn fablet/Youenn Fablet/
08:49:08 [fjh]
q?
08:49:11 [Josh_Soref]
s/youenn/scribe/
08:49:17 [bryan]
anssik: so the harness API does not support
08:49:24 [Josh_Soref]
s/Youenn Fablet/youenn: Youenn Fablet/
08:49:24 [bryan]
dom: not sure
08:49:29 [mounir]
q+
08:49:39 [Josh_Soref]
present+ Jinhong_Yong
08:49:50 [Josh_Soref]
present+ Giri_Mandyam
08:50:13 [Josh_Soref]
s/+q/q+/
08:50:17 [bryan]
dom: one of the difficulties is testing the API itself and also how it is developed in an implementation
08:50:35 [bryan]
jungkee: haven't tried this test yet (richt asked)
08:50:48 [fjh]
ack gmandyam
08:51:18 [spoussa]
spoussa has joined #dap
08:51:21 [bryan]
giri: these are assert tests
08:51:53 [bryan]
gmandyam: until you have fully charged the battery you can't verify the implementation
08:52:17 [richt]
AnssiK: re: my question to Jungkee. Tests are very new (1 day old) so they have not been run against the Tizen impl yet.
08:52:18 [bryan]
fjh: what I heard is that the test that matters are fully charging and discharging?
08:52:33 [SungOk_You]
SungOk_You has joined #dap
08:52:47 [bryan]
gmandyam: time to discharge test requires a full discharge to verify
08:53:12 [bryan]
anssik: what you cant do in automated tests is determine if the reported value is the actual value
08:53:25 [bryan]
... you have to check with other data e.g. at the OS level
08:54:02 [bryan]
gmandyam: have compared whats in the OS vs what's in javascript, and found differences... should we consider that in the tests?
08:54:18 [Josh_Soref]
q+
08:54:35 [richt]
is that difference a rounding error gmandyam, or something more serious?
08:54:35 [bryan]
anssik: it's up to the glue layer to define any translations exposed to the browser
08:55:10 [bryan]
gmandyam: can we really say an implementation is compliant, it the reading varies from the OS?
08:55:31 [bryan]
richt: is this a rounding error or a bigger difference?
08:55:40 [Daniel_Samsung]
Daniel_Samsung has joined #Dap
08:56:23 [bryan]
gmandyam: it was pretty significant, almost a latency of the javascript, when a significant change occured at the OS vs when it showed up in the javascript
08:57:33 [fjh]
q?
08:57:36 [fjh]
ack dom
08:57:36 [Zakim]
dom, you wanted to mention idlharnes
08:57:38 [bryan]
mounir: we use the exact value that the OS tells you (thru the API), to avoid fingerprinting we take steps
08:57:38 [shan]
shan has joined #dap
08:58:27 [bryan]
dom: there is a test harness for webidl, which will run most of those types of tests automatically. we should use that as it can save work for those type of tests
08:58:29 [mounir]
mounir: our implementation only use OS APIs and try to comptue values if there is no such APIs so you shouldn't see difference except rounding values because we try to round to prevent too much fingerprinting (0.1234567 => 0.12)
08:59:07 [bryan]
... also how much linking test cases with assertions so far?
08:59:21 [fjh]
q?
08:59:23 [bryan]
anssik: about 90%
08:59:46 [Josh_Soref]
RRSAgent, draft minutes
08:59:46 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
09:00:43 [bryan]
... looking at the spec (highlighting how paragraphs map to tests), its not so easy to separate tests back to prose
09:00:59 [bryan]
dom: and thanks for getting these tests done
09:01:07 [fjh]
ack mounir
09:01:08 [mounir]
ack
09:01:13 [bryan]
anssik: it's been good to work with mounir, a good collaboration
09:01:21 [bryan]
mounir: to report the issues we have found
09:02:04 [Josh_Soref]
present+ Shin-Gak_Kang
09:02:14 [bryan]
... it's hard to test this in hardware, so we are using emulators
09:02:35 [bryan]
... so we change the value in the emulator and verify the change thru the API
09:02:57 [bryan]
... every platform has different implementations, we have found bugs in different OS
09:03:08 [Josh_Soref]
present+ Wook_Hyun
09:03:15 [bryan]
... it's not as easy to check any version to see if it's conforming
09:03:18 [fjh]
q?
09:03:22 [fjh]
ack Josh_Soref
09:04:04 [bryan]
Josh_Soref: one of the goals was to disclose when the device is about to run out of battery, so the app can take action
09:04:25 [bryan]
... some divergence is acceptable between the system and user perception
09:04:41 [fjh]
q?
09:04:45 [richt]
q+
09:04:47 [bryan]
... that this is different from some other estimate that is questionable is not a valid concern
09:04:59 [dom]
ack richt
09:05:25 [bryan]
richt: a lot of what we say here for battery will apply to the other APIs, so maybe we can move quicker based upon this discussion
09:05:27 [gmandyam]
q+
09:05:45 [bryan]
... so I can test if the feature is supported thru the API?
09:05:59 [bryan]
mounir: (responds)
09:06:02 [mounir]
mounir: the spec defines default values
09:06:10 [Josh_Soref]
present+ Sung_Hei_Kim
09:06:20 [mounir]
mounir: we return those default values if we don't have the backend implemented for the platform
09:06:24 [Josh_Soref]
present+ Juan_Ji
09:06:39 [bryan]
anssik: if you expose the object but don't have the implementation, we test for that, to avoid fingerprinting via a dummy interface
09:06:39 [Josh_Soref]
s/mounir:/mo_unir:/
09:06:43 [Josh_Soref]
s/mounir/scribe/
09:06:45 [fjh]
q?
09:06:49 [Josh_Soref]
s/mo_unir:/mounir:/
09:06:54 [fjh]
ack
09:06:56 [Josh_Soref]
RRSAgent, draft minutes
09:06:56 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
09:06:57 [fjh]
q?
09:06:59 [fjh]
q-
09:07:09 [AnssiK]
this test is for devices that expose the BatteryManager interface, but lack a backend implementation: http://w3c-test.org/dap/battery/tests/submissions/anssik/battery-created.html
09:07:09 [fjh]
ack gmandyam
09:07:19 [Milan_Patel]
Milan_Patel has joined #dap
09:07:23 [bryan]
gmandyam: based upon the mobile perspective, we're trying to get developers aware of battery state
09:07:44 [bryan]
... the level is clearly an estimate, but consistency with the OS is important
09:07:45 [shunan]
shunan has joined #dap
09:07:51 [fjh]
q+
09:07:59 [AnssiK]
… as well as this one: http://w3c-test.org/dap/battery/tests/submissions/anssik/battery-interface.html
09:08:09 [bryan]
... I tested the mozilla implementation as input to a paper for the web performance workshop next week
09:08:28 [seo]
seo has joined #dap
09:08:48 [bryan]
... when I discharged the battery all the way, there was a clear discrepancy in the javascript (20-30%)
09:08:53 [AnssiK]
[the first test is useful *only* if there's no backend impl]
09:09:04 [fjh]
q?
09:09:14 [bryan]
Josh_Soref: that's the type of bug we need to see reported
09:09:23 [mounir]
gmandyam: on which platform?
09:09:23 [bryan]
fjh: so next steps with this work
09:09:24 [fjh]
ackfjh
09:09:28 [fjh]
a/ackfjh//
09:09:30 [fjh]
q?
09:09:33 [fjh]
ack fjh
09:09:45 [Josh_Soref]
s/reported/reported (it's ok, for the UA battery report to indicate dying sooner, but not ok to report dying after the OS)/
09:09:54 [bryan]
anssik: will continue on the tests, will test tizen devices when available (also firefox OS, please provide one!)
09:10:08 [bryan]
... about the next process step
09:10:51 [bryan]
richt: before we have finished specs, and shelved with no implementations. we should expect some inertia now, and some time before wider implementations
09:11:20 [Josh_Soref]
RRSAgent, draft minutes
09:11:20 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
09:11:22 [bryan]
... its not a huge concern to get to PR, but we cant progress at this point though the spec is still alive
09:11:42 [fjh]
fjh has changed the topic to: dap 3279 ; http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France
09:11:42 [bryan]
anssik: IP committments kick in so we need to get there asap
09:11:59 [bryan]
dom: until we get another browser implementation the question is pretty moot
09:12:07 [fjh]
action: dom to review Battery test and contribute more tests
09:12:07 [trackbot]
Created ACTION-585 - Review Battery test and contribute more tests [on Dominique Hazaël-Massieux - due 2012-11-08].
09:12:33 [bryan]
anssik: would be better if someone else also contributes tests
09:12:53 [bryan]
richt: lack of implementation does not imply disagreement (want to make that key point)
09:12:55 [Josh_Soref]
RRSAgent, draft minutes
09:12:55 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
09:13:09 [AnssiK]
s/kick in/kick in in REC/
09:13:11 [Josh_Soref]
s|a/ackfjh//||
09:13:18 [Josh_Soref]
s|ackfjh||
09:13:27 [Josh_Soref]
RRSAgent, draft minutes
09:13:27 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
09:13:37 [bryan]
dom: we have made a call for implementations, otherwise the spec is ready
09:14:15 [bryan]
richt: there doesn't seem to be disagreement, just not clear and broad agreement
09:14:34 [bryan]
dom: one open question, what is the process for approving test suites
09:14:49 [bryan]
... by default, by review, etc
09:15:19 [bryan]
... the default is that they are approved until problems are found
09:15:33 [bryan]
richt: think we should have a code review
09:15:43 [bryan]
... W3C should have such systems in place
09:15:53 [fjh]
action: richt to review Battery tests
09:15:54 [trackbot]
Created ACTION-586 - Review Battery tests [on Richard Tibbett - due 2012-11-08].
09:16:09 [JonathanJ1]
JonathanJ1 has joined #DAP
09:17:34 [bryan]
topic: Vibration API
09:17:46 [Josh_Soref]
s|heard about a blackberry implementation|-> https://developer.blackberry.com/html5/apis/blackberry.system.html#.event:batterystatus "BlackBerry 10" implementation|
09:17:49 [bryan]
anssik: spec is in CR since may
09:17:52 [Josh_Soref]
RRSAgent, draft minutes
09:17:52 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
09:18:15 [nwidell]
nwidell has joined #dap
09:18:20 [bryan]
... minor clarifications, implemented in firefox OS, tizen. test suite draft by robin
09:19:00 [bryan]
mounir: also firefox android
09:19:14 [AnssiK]
* spec in CR since May 2012: http://dev.w3.org/2009/dap/vibration/
09:19:30 [AnssiK]
* minor clarifications since CR, changelog: http://dev.w3.org/cvsweb/2009/dap/vibration/Overview.html
09:19:40 [bryan]
anssik: its exposed to the browser but if it doesn't have the hardware it won't do anything
09:19:45 [fjh]
q?
09:19:55 [AnssiK]
* implementation status: Firefox, Firefox for Android, Firefox OS, WebKit: http://www.w3.org/2009/dap/wiki/ImplementationStatus#Vibration_API
09:20:08 [AnssiK]
* test suite draft by darobin: http://w3c-test.org/dap/tests/vibration/submissions/robin/
09:20:28 [AnssiK]
* test suite TODOs: http://w3c-test.org/dap/tests/vibration/submissions/robin/TODO.txt
09:20:35 [AnssiK]
* next: work on the test suite
09:20:40 [bryan]
wonsuk: clarifying, wekbit supports many browsers based upon linux (a lot of ports)
09:21:18 [Yuan]
s/Juan_J/Yuan_J/
09:21:19 [bryan]
... the EFL port has many browsers in testing. this may be helpful to CR?
09:21:31 [bryan]
... (this was related to the battery API, not Vibration)
09:22:00 [bryan]
... Tizen is a Web-based OS, but provides different context (system app and browser)
09:22:40 [bryan]
... we can provide test results based upon tizen for our target devices. will that be helpful to move to CR for the battery API?
09:22:43 [giuseppe]
giuseppe has joined #dap
09:23:21 [bryan]
fjh: will the open-source status of the browser should help (this is the question)
09:23:42 [noriya]
noriya has joined #DAP
09:23:44 [bryan]
dom: is it a shipping browser that has battery, or an experiment
09:24:10 [bryan]
wonsuk: its testable in a test environment based upon the EFL port
09:24:26 [bryan]
dom: what we want is real browsers that are shipping
09:24:39 [bryan]
richt: 2 is the minimum
09:25:08 [fjh]
bryan: does browser implementation mean installable on any platform?
09:25:28 [fjh]
josh: apis for general web apps for general browsers in general deployments
09:25:40 [fjh]
josh: test implementation not suitable for exiting C
09:25:43 [fjh]
s/C/CR/
09:26:03 [bryan]
josh_soref: the browser needs to be a major browser, not puppet implementations
09:26:07 [fjh]
s/shipping/shipping to leave CR/
09:26:45 [fjh]
need to clarify in battery API status that exit criterial for CR is 2 independent real world browsers
09:26:49 [bryan]
dom: technically we need to have two implementations, two real-world implementations independently sourced
09:26:51 [Josh_Soref]
s/josh:/Josh_Soref:/G
09:26:55 [Josh_Soref]
s/josh_soref:/Josh_Soref:/G
09:27:44 [Daniel]
Daniel has joined #Dap
09:27:58 [fjh]
ISSUE: status section of Battery CR draft should include exit criteria and at-risk items
09:27:59 [trackbot]
Created ISSUE-127 - Status section of Battery CR draft should include exit criteria and at-risk items ; please complete additional details at http://www.w3.org/2009/dap/track/issues/127/edit .
09:28:17 [bryan]
bryan: we are expecting real world implementations expected for wide use, not just the "big five"
09:28:59 [GregBillock]
re: battery implementation in webkit, see https://trac.webkit.org/browser/trunk/Source/WebCore/Modules/battery
09:29:22 [GregBillock]
(I don't see it is enabled by any webkit-based browser currently.)
09:29:38 [bryan]
dom: we need an exit criteria (not necessarily well-defined), and the director will make a decision whether we have really met the criteria
09:31:14 [nkic]
nkic has joined #dap
09:56:20 [a1zu]
a1zu has joined #dap
09:58:31 [kotakagi]
kotakagi has joined #dap
10:00:07 [shan]
RRSAgent, draft minutes
10:00:07 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html shan
10:02:07 [nwidell]
nwidell has joined #dap
10:02:30 [Hidetoshi]
Hidetoshi has joined #dap
10:03:45 [kenji]
kenji has joined #dap
10:05:02 [adrianba]
adrianba has joined #dap
10:05:10 [giuseppe]
giuseppe has joined #dap
10:06:26 [comus]
comus has left #dap
10:06:44 [darobin]
darobin has joined #dap
10:06:49 [smaug]
smaug has joined #dap
10:07:41 [Geun_hyung]
Geun_hyung has joined #dap
10:08:11 [Geun_hyung]
present+ Geun-Hyung_Kim
10:08:51 [a12u]
a12u has joined #dap
10:09:10 [nwidell]
nwidell has joined #dap
10:10:02 [spoussa]
spoussa has joined #dap
10:12:08 [bryan]
topic: HTML Media Capture
10:12:18 [bryan]
fjh: we have a LCWD with some feedback
10:12:24 [npdoty]
npdoty has joined #dap
10:14:15 [shoko_]
shoko_ has joined #dap
10:14:17 [fjh]
general comment on HTML Media Capture comment http://lists.w3.org/Archives/Public/public-device-apis/2012Oct/0050.html
10:14:17 [jfmoy]
jfmoy has joined #dap
10:14:35 [bryan]
shepazu is here
10:14:35 [youenn]
youenn has joined #dap
10:14:35 [jgiraud]
jgiraud has joined #dap
10:15:02 [GregBillock]
GregBillock has joined #dap
10:15:10 [bryan]
fjh: thought about comments of doug
10:15:24 [bryan]
... e.g. might want mic vs video, different use cases
10:15:32 [Wonsuk]
Wonsuk has joined #dap
10:15:33 [jiro]
jiro has joined #dap
10:15:40 [bryan]
... other comments about front vs back and selection
10:15:48 [bjkim]
bjkim has joined #dap
10:16:13 [bryan]
... other work in media capture, with streams and tracks etc... this seems related to the goals
10:16:16 [jcdufourd]
jcdufourd has joined #dap
10:16:34 [bryan]
... maybe that's the solution, and it shouldn't be in html media capture
10:16:43 [bryan]
bryan: +1 to reuse
10:16:57 [shepazu]
shepazu has joined #dap
10:17:15 [bryan]
fjh: mime types dont seem to relate to the track objectives etc... what problems are we trying to solve?
10:17:33 [bryan]
shepazu: comments are more about setting correct usability and privacy expectations
10:18:00 [bryan]
... e.g. get camcorder. does that necessarily include audio, is video recording automatically include audio?
10:18:23 [bryan]
anssik: think that users will expect what the native platform would provde
10:18:41 [bryan]
... that is an implementation concern
10:18:49 [Josh_Soref]
present+ Doug_Schepers_(shepazu)
10:18:55 [fjh]
q+
10:19:04 [bryan]
dom: to be clear, the html media capture is a shortcut to enable recording
10:19:19 [Yuan]
Yuan has joined #dap
10:19:22 [bryan]
... giving direct access to the native application through a button for example
10:19:54 [bryan]
... the user doesn't have to 1st record and then upload. but it still uses the basic OS framework, and nothing extra
10:20:08 [bryan]
... the media capture API will provide that
10:20:15 [dom]
q+ olivier
10:20:20 [bryan]
fjh: we need an intro section setting expectations
10:20:28 [dom]
ack fjh
10:20:36 [Josh_Soref]
q?
10:20:37 [bryan]
shepazu: the rewrite should address the relationship with getusermedia
10:20:45 [sunghan]
sunghan has joined #dap
10:20:53 [bryan]
fjh: agree we have a spec that is unclear per the landscape
10:21:19 [bryan]
shepazu: need to clarify that "camcorder" includes audio. that needs to be clear.
10:21:32 [bryan]
dom: again camcorder only starts the native application
10:21:41 [kensaku]
kensaku has joined #dap
10:21:46 [bryan]
shepazu: in that case the author needs to know if they will get audio
10:21:51 [fjh]
I propose we update the abstract and introduction to clarify the purpose and limitations of the spec, relationship to getusermedia etc and this should help address the concerns
10:22:09 [fjh]
clarify as Dom mentioned that is shortcut for file upload
10:22:14 [bryan]
dom: the application just hands the user to the native feature
10:22:15 [Josh_Soref]
s/fjh/scribe/
10:22:16 [Josh_Soref]
s/fjh/scribe/
10:22:25 [Josh_Soref]
s/I propose/fjh: I propose/
10:22:26 [shepazu]
http://www.w3.org/2012/09/26-audio-minutes.html#item05
10:22:35 [Josh_Soref]
s/clarify/fjh: clarify/
10:22:42 [Josh_Soref]
RRSAgent, draft minutes
10:22:42 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
10:22:43 [bryan]
... normal operations result and when coming back to the app, the user will find the file and then upload etc
10:22:56 [bryan]
shepazu: upload what, does it include audio?
10:23:09 [dom]
ack olivier
10:23:12 [bryan]
dom: if you need more control from the app, you need to use getusermedia
10:23:16 [fjh]
q+
10:23:47 [shepazu]
Audio WG concerns with HTML Media Capture API -> http://www.w3.org/2012/09/26-audio-minutes.html#item05
10:24:08 [bryan]
olivier: there are different perspectives on what features are involved here, but it doesn't sound future proof
10:24:11 [Josh_Soref]
s|Audio WG concerns with HTML Media Capture API -> http://www.w3.org/2012/09/26-audio-minutes.html#item05|-">http://www.w3.org/2012/09/26-audio-minutes.html#item05|-> http://www.w3.org/2012/09/26-audio-minutes.html#item05 Audio WG concerns with HTML Media Capture API|
10:24:18 [Josh_Soref]
RRSAgent, draft minutes
10:24:18 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
10:24:32 [bryan]
... we are talking about images, audio, and video, not just what devices give you those
10:24:53 [bryan]
... from the audio WG we are worried that there are two APIs providing the same things
10:25:06 [bryan]
anssik: we do need to clarify the keywords
10:25:22 [bryan]
... e.g. capture is "still image capture device"
10:25:31 [bryan]
s/capture/camera/
10:25:33 [noriya]
noriya has joined #DAP
10:25:48 [bryan]
... and camcorder is a "motion capture device"
10:26:16 [bryan]
shepazu: is this the wording or the keywords that are proposed to be changed?
10:26:42 [bryan]
... motion capture can be haptic etc, would suggest to use "video"
10:26:56 [bryan]
fjh: how real an issue is "camcorder" vs video?
10:27:08 [bryan]
olivier: the concern is more about consistency
10:27:26 [bryan]
shepazu: camcorder is an old term
10:28:13 [bryan]
josh_soref: (proposes an experiment)
10:28:36 [Josh_Soref]
s/experiment -- and it fails -- miserably/
10:28:44 [bryan]
richt: i am a web developer with lot of tools, this is about getting a file of the type that comes from the camcorder, or the camera, or scanner etc
10:29:17 [bryan]
... more generally, we have a "accept" attribute that enables selection of the type of file to get
10:29:22 [Josh_Soref]
q+ to say that the option thing is silly since, ideally the UA will just do this automatically
10:29:30 [kotakagi]
kotakagi has joined #dap
10:29:48 [bryan]
... what ends up is a launch with filtering of the selected tools
10:30:03 [bryan]
... it's fine the way it is
10:30:11 [YOshihiro]
YOshihiro has joined #dap
10:30:46 [Yoshihiro]
Yoshihiro has joined #dap
10:30:54 [bryan]
shepazu: agree that there is a place for this, it addresses use cases getusermedia does not
10:30:58 [gmandyam]
q+
10:31:13 [a12u]
a12u has joined #dap
10:31:26 [bryan]
... we need more explanation of how HTML is being extended, and that expectations for the author and user are not being clarified
10:31:52 [bryan]
... don't want the author to guess what the app will offer to the user
10:32:13 [bryan]
fjh: we got a comment that we need more clear text
10:32:16 [dom]
ack fjh
10:32:38 [bryan]
anssik: we do need to more clearly describe how the options address the different use cases
10:32:53 [bryan]
shepazu: that would help, for that part of it
10:33:27 [bryan]
fjh: so there is not enough info for a first time reader to understand, and we need to improve that
10:33:59 [bryan]
dom: doug had another point, not just the link with HTML, but that he needs more info about what is exposed to the user through the UI
10:34:23 [bryan]
fjh: we need to say something related to the content in the file (audio vs video)
10:34:57 [bryan]
richt: offloading to a native app, we often can't tell the native app what we expect. it's not a feature of the native app to allow that control
10:35:09 [bryan]
... you get just the ability to select a file type
10:35:35 [bryan]
shepazu: it's not just the file. you are interacting with the application, e.g. a video camera, not a file type
10:35:55 [bryan]
dom: we are not getting a camera, but the file object
10:36:04 [jinhong]
jinhong has joined #dap
10:36:14 [bryan]
... what does is saying is that informative language update may not be enough
10:36:31 [Josh_Soref]
-> http://welcome.solutions.brother.com/BSC/FAQ_IKOU_IMG/faq000717_000/my_comp1.gif file picker with scanner
10:36:42 [fjh]
q-
10:36:46 [bryan]
... once you have the file, the app may be able guide the user to do something different as needed by the app
10:36:55 [AnssiK]
q+
10:36:58 [fjh]
ack josh_soref
10:36:58 [Zakim]
Josh_Soref, you wanted to say that the option thing is silly since, ideally the UA will just do this automatically
10:37:06 [kinji]
kinji has joined #dap
10:37:06 [bryan]
... if the app needs more control, then it needs to use getusermedia
10:37:22 [bryan]
josh_soref: dropped in picture links
10:37:22 [Josh_Soref]
-> http://www.computing-tips.net/img/avacam_webcam.gif file picker with cameraq
10:37:40 [spoussa]
q?
10:38:07 [bryan]
... want to note that people used to think of windows explorer as a file picker
10:38:36 [bryan]
... this is now false, the picker can show other things as virtual files e.g. a scanner
10:39:20 [bryan]
... the picker can offering ways to get data of a source, that could include hints to the user
10:39:41 [bryan]
... the user can select different sources of the same type, e.g. an image or a camera
10:40:18 [bryan]
... but in the end it's just a file that is being selected. if more is needed the app should use getusermedia
10:40:45 [Josh_Soref]
q?
10:40:47 [Josh_Soref]
ack gmandyam
10:41:08 [Josh_Soref]
s/cameraq/camera/
10:41:27 [bryan]
gmandyam: a broader perspective, prior to joining the DAP WG, ...
10:41:44 [bryan]
... I heard two arguments in favor of html media capture
10:42:06 [bryan]
... the first is a bogus argument, don't see the value in adding a new DOM element just for capture
10:42:23 [bryan]
... also the argument over the privacy approach is bogus
10:42:23 [dom]
q+
10:42:54 [dom]
q+ richt
10:43:03 [bryan]
... even though getusermedia is still being developed, we can expect that a dialog box will provide the user with options also
10:43:07 [fjh]
q+
10:43:10 [youenn]
youenn has joined #dap
10:43:26 [bryan]
... in the next few months we will have similar and better capabilities with getusermedia
10:43:31 [Josh_Soref]
ack dom
10:44:03 [bryan]
dom: responding, was at the mediacapture TF meeting, and its optimistic that in 6 mos we will have a stable spec
10:44:05 [Josh_Soref]
Josh_Soref: +1 (i minuted)
10:44:09 [Josh_Soref]
s/its/it's/
10:44:37 [bryan]
... there are also may use cases that dont need control of the camera, just need a file e.g. picture that can be acted upon
10:45:01 [Josh_Soref]
RRSAgent, draft miinutes
10:45:01 [RRSAgent]
I'm logging. I don't understand 'draft miinutes', Josh_Soref. Try /msg RRSAgent help
10:45:02 [bryan]
... a simple declarative way to get a picture without dependency upon detailed features
10:45:03 [Josh_Soref]
RRSAgent, draft minutes
10:45:03 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
10:45:10 [fjh]
+1 to having simple interface for functionality in addition to getusermedia that offers more control
10:45:24 [bryan]
... coremob also has identified the use cases of getting a picture as important
10:45:52 [bryan]
gmandyam: expect javascript libraries to extract away the complexity for those apps that need just a simple picture capture
10:46:44 [Josh_Soref]
ack richt
10:46:50 [bryan]
dom: agree libraries can also get the same output, but the library can't expose things equivalent to the default UI of the device
10:47:20 [Josh_Soref]
RRSAgent, draft minutes
10:47:20 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
10:47:23 [bryan]
richt: the way to look at this, with the file input type, that you get a file picker. all the spec does is enable innovation at the file picker level
10:47:43 [bryan]
... this is not about control over the file, just selection
10:47:49 [fjh]
q?
10:48:00 [bryan]
... making it easier for the users to get to the file (type) they want to share
10:48:04 [shepazu]
q+
10:48:08 [nwidell]
q+
10:48:14 [fjh]
"a quicker picker"
10:48:19 [bryan]
... purely innovation at the file picker level
10:48:29 [shepazu]
q+ to support the use cases for this spec
10:48:37 [fjh]
ack AnssiK
10:48:37 [bryan]
anssik: love getusermedia, great for its use cases
10:49:11 [GregBillock]
GregBillock has joined #dap
10:49:11 [bryan]
... note that form based file upload was in HTML 2 in 1995, well tested over the last 17 years. the UI is a non-issue
10:49:28 [nkic]
nkic has joined #dap
10:49:57 [bryan]
... additional point for doug, about privacy/security. if an app wants audio + video, but I don't want audio just the video, ...
10:50:11 [bryan]
... i need the freedom to get the video without the audio
10:50:44 [Josh_Soref]
ack fjh
10:50:56 [bryan]
shepazu: you should be able to express what you want, and the user should be able to modify that
10:51:27 [richt]
q?
10:51:29 [richt]
q+
10:51:33 [bryan]
... saying accept to one file type, doesn't necessarily imply both types of content are acceptable
10:52:10 [bryan]
... want the user to know what the app's expectation is, and to give the user the option to choose
10:52:38 [bryan]
dom: html can be used to express to the user what the app expects, before they click the button
10:53:16 [gmandyam]
Has anyone effectively rebutted the arguments in the HTML5 Rocks article on gUM vs. HTML Media Capture? See http://www.html5rocks.com/en/tutorials/getusermedia/intro/
10:53:17 [bryan]
richt: understand the intent, that user opt-in to audio is important
10:53:49 [bryan]
... that's not a feature of the native application, to offer that control by an API of the platform
10:54:36 [kinji]
kinji has joined #dap
10:54:36 [bryan]
shepazu: when you popup the dialog, you chrome can't popup something that clarifies what is asked for?
10:54:39 [a12u]
a12u has joined #dap
10:55:15 [bryan]
josh_soref: the popup will be the native recorder, and the only browser interface is to run the native app, and to receive the output file
10:55:35 [bryan]
shepazu: you can ask it, whether it listens is another matter
10:56:16 [bryan]
olivier: at the moment you can, but specifying it is a start and will promote development of the native APIs
10:56:17 [gmandyam]
q+
10:56:28 [nwidell]
q-
10:56:35 [Josh_Soref]
ack shepazu
10:56:35 [Zakim]
shepazu, you wanted to support the use cases for this spec
10:56:38 [dom]
q+
10:56:44 [richt]
q-
10:56:48 [bryan]
shepazu: those who are developing platforms are in control, and can develop this. we just need to make it possible thru the spec
10:57:13 [bryan]
... the audio WG wants the html media capture spec, to get to market quickly.
10:57:32 [bryan]
... getusermedia will take longer, and in the meantime this is critically important
10:57:35 [fjh]
q+
10:57:44 [bryan]
... really support the spec, but want it to be done right
10:58:07 [bryan]
dom: the only thing not possible is to enable recording of video only?
10:58:17 [bryan]
... to separate the video and audio?
10:58:31 [bryan]
... what is the use case, when would you want that?
10:58:46 [Wonsuk]
Wonsuk has joined #dap
10:59:02 [Josh_Soref]
q?
10:59:03 [bryan]
shepazu: if you want videos, but have privacy concern about the collection of an audio track
10:59:39 [bryan]
richt: we could put that in the dialog, and hand off to the native app, then strip the audio out
10:59:45 [Josh_Soref]
q+ to say that if we offer this stripping and fail to do it, there's probably more liability
10:59:46 [npdoty]
there are some legal jurisdictions where recording audio requires a higher legal bar than capturing video, fwiw
10:59:53 [bryan]
shepazu: not asking for that, just to inform the user
11:00:06 [dom]
ack me
11:00:06 [AnssiK]
AnssiK has left #dap
11:00:33 [AnssiK]
AnssiK has joined #dap
11:00:51 [bryan]
fjh: would it help to have keywords to allow the separate source types to be included
11:01:01 [noriya]
noriya has joined #DAP
11:01:29 [bryan]
shepazu: more keywords seems more complex... my solution is to have a list of what is requested
11:01:54 [bryan]
fjh: so what olivier is requesting is that we think ahead
11:03:04 [richt]
s/and hand off to the native app, then strip the audio out/and hand off to the native app, have a File returned, then strip the audio out, and return the modified File to the calling web page./
11:03:12 [Josh_Soref]
-> http://supportforums.blackberry.com/t5/image/serverpage/image-id/10499i92514F6021C56011/image-size/original?v=mpbl-1&px=-1 BlackBerry File Picker with Camera
11:03:18 [bryan]
gmandyam: a question, if we think a separate file picker should be provided for this API, for devices that have file pickers already, what are we providing beyond the UI of the native app which the user might already be comfortable with?
11:04:14 [fjh]
q?
11:04:20 [bryan]
richt: if i want to upload a profile photo, today I pick a file through the browser, or I exit the browser record a picture go back etc... this shortcuts that loop
11:04:21 [fjh]
ack gmandyam
11:05:21 [bryan]
gmandyam: enabling a user experience not possible today is fine, but that somewhat contradicts the assertion that the user only needs to work with the native UI
11:05:40 [bryan]
richt: getusermedia is about staying in the browser and getting the media
11:06:04 [bryan]
... this otoh is about switching to the native app seamlessly
11:06:05 [Josh_Soref]
q?
11:06:17 [olivier1]
olivier1 has joined #dap
11:06:30 [bryan]
... they are different use cases and both needed. there is no choice between these, they are both important
11:07:00 [Wonsuk]
+1 for richt
11:07:08 [bryan]
fjh: suggest we get to the LC concerns and address them well
11:07:29 [AnssiK]
LC comments: https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/doc/
11:07:42 [bryan]
... it would be useful to look at the LC comments each to see if something has been missed, or is it this one issue?
11:07:50 [JonathanJ1]
rrsagent, draft minutes
11:07:50 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html JonathanJ1
11:08:13 [bryan]
josh_soref: doug wants to specify what is requested
11:08:22 [nwidell]
nwidell has joined #dap
11:08:25 [ot]
q+
11:09:04 [bryan]
... (showing the blackberry UI)
11:09:20 [bryan]
... we can already map the accept list to this type of dialog
11:09:44 [bryan]
fjh: can you do the camcorder case without audio?
11:10:08 [bryan]
josh_soref: probably not today
11:10:54 [bryan]
... if we told the user we would not provide a certain type of content (e.g. audio) and failed, we would be in trouble potentially
11:11:27 [bryan]
shepazu: i understand where you are coming from, maybe rewrites can make it clearer
11:11:31 [a12u]
a12u has joined #dap
11:11:54 [Takahiro]
Takahiro has joined #dap
11:11:59 [jmr_]
jmr_ has joined #dap
11:12:14 [bryan]
olivier: a lot of the discomfort came from the spec being unclear. from today, i recommend renaming it to "media file" capture
11:12:52 [bryan]
richt: a demo may help clear this up
11:13:12 [richt]
richt: Josh_Soref has a demo that people should look at during the break.
11:13:26 [bryan]
fjh: we have some more time, and have covered doug's concerns (though not solved them)
11:14:00 [bryan]
... you believe that we should provide the ability to ask for more granularity
11:14:19 [bryan]
shepazu: yes, from a privacy perspective there is additional work needed
11:14:50 [bryan]
... also it would be useful to share discussion with the audio WG
11:15:14 [bryan]
... some overlapping members can help us discuss this
11:15:38 [bryan]
fjh: we should go thru the other comments now
11:15:50 [bryan]
josh_soref: (showing a demo)
11:16:05 [bryan]
... facebook, with a photo button
11:16:58 [bryan]
... on click the button, files are offered but don't want them. another option is the selection of a new picture
11:17:54 [bryan]
... the same behavior applies to other recording cases
11:18:09 [bryan]
fjh: going to other LC comments
11:19:17 [bryan]
... 2641 was about front/back
11:19:47 [bryan]
anssik: this relates to the same discussion about audio/video... you should use getusermedia instead
11:20:08 [bryan]
... 2637 is one we have to decide on, but not now
11:20:35 [bryan]
... 2640, about html will be easy to resolve
11:21:05 [bryan]
... 2638, asking for an example, we can say this is solved and do it with the other comments of doug
11:21:53 [bryan]
... 2639, re camcorder as name, this seems not an issue anymore... any objectors in the room? if not, propose that we close this one
11:22:00 [gmandyam]
q
11:22:04 [gmandyam]
+q
11:22:13 [bryan]
... lack of speaking up means consent
11:22:37 [npdoty]
npdoty has joined #dap
11:22:52 [bryan]
nwidell: what is the relationship of the use of camcorder for getusermedia?
11:23:02 [Josh_Soref]
-> http://dev.w3.org/2011/webrtc/editor/getusermedia.html GetUserMedia
11:23:07 [Josh_Soref]
Access to multimedia streams (video, audio, or both) from local devices (video cameras, microphones, Web cams) can have a number of uses, such as real-time communication, recording, and surveillance.
11:23:07 [bryan]
fjh: they talk about tracks and streams, so they don't need to go there
11:23:15 [Josh_Soref]
s/Josh_Soref/scribe/
11:23:56 [bryan]
... 2642 is done, not sure there was a response yet. we dont need to do anything more until a response
11:24:18 [Travis]
Travis has joined #dap
11:24:21 [bryan]
... 2644, is addressed and done, and response is OK so this is closed
11:24:26 [jiro]
jiro has joined #dap
11:25:01 [AnssiK]
LC-2644 +1'd by commentor at: http://www.w3.org/mid/001401cd96e5$7a73f7b0$6f5be710$@murthy@cmcltd.com
11:25:09 [bryan]
... two things needed to do, informative changes (any contributors welcome)
11:25:23 [nwidell]
(intent of my question was just if there was a need to align attribute names e.g. "camcorder" with somthing equivalent in getUserMedia
11:25:32 [bryan]
... also to rename it to "HTML Media File Capture"
11:26:01 [bryan]
bryan: is this just to be clear that a discrete file is delivered vs a stream?
11:27:17 [AnssiK]
"HTML Media Capture" v "Media Capture and Streams"
11:27:37 [bryan]
fjh: 3rd things is to resolve the audio/video selection
11:27:53 [fjh]
s/rename it to "HTML Media File Capture/ rename it for clarity, possibly HTML Media File capture/
11:27:54 [bryan]
bryan: they should be fine with the name, HTML makes it clear this is declarative
11:28:07 [fjh]
s/rename/consider renaming/
11:28:15 [bryan]
anssik: also don't think we need to rename, they should be fine with this
11:29:01 [Wonsuk]
Wonsuk has left #dap
11:29:40 [bryan]
fjh: so we are done with this?
11:29:42 [Josh_Soref]
present+ Travis_Leithead
11:30:38 [bryan]
fjh: would like to do more on vibration and wrap that up
11:31:31 [bryan]
fjh: we were talking about how it couldn't be generic as not all platforms have this feature, and testing
11:31:35 [AnssiK]
http://w3c-test.org/dap/tests/vibration/submissions/robin/TODO.txt
11:31:58 [bryan]
anssik: we have a todo list
11:32:37 [bryan]
... i volunteered to write the tests, welcome any support. also need some hardware to test it on.
11:32:37 [olivier1]
olivier1 has joined #dap
11:32:44 [olivier2]
olivier2 has joined #dap
11:32:53 [bryan]
mounir: believe its in firefox OS
11:33:08 [bryan]
anssik: is there a way to emulate it somehow?
11:33:38 [bryan]
... will take it offline, and talk with tizen for testing
11:34:06 [bryan]
jungkee: samsung colleagues implemented this for webkit
11:35:20 [bryan]
fjh: so we need hardware and tests for vibration to proceed?
11:35:40 [bryan]
anssik: writing test cases is boring without hardware to test against
11:35:59 [bryan]
fjh: going on to proximity and ambient light sensors
11:36:08 [spoussa]
me can give AnssiK Tizen reference device for battery and vibra testing.
11:36:38 [bryan]
gmandyam: the call for exclusions for ambient light just came out
11:37:22 [bryan]
anssik: we have one implementation for proximity events, and it shares the design for ambient light
11:37:42 [bryan]
... at least for proximity, we could move to LC. marcos did the tests for it
11:38:27 [bryan]
gmandyam: Ian sent an email today for exclusion
11:38:52 [bryan]
fjh: need to know if the WG thinks the specs are stable and can move to LC
11:39:18 [AnssiK]
* spec WD in Jul 2012: http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html
11:39:27 [AnssiK]
* test suite: http://w3c-test.org/dap/proximity/tests/submissions/marcos/
11:39:35 [bryan]
fjh: who is involved with ambient light?
11:39:48 [bryan]
... can do a CFC
11:39:54 [Josh_Soref]
s/CFC/CfC/
11:40:12 [bryan]
proposed RESOLUTION: publish a LCWD of the Proximity Events spec
11:41:04 [bryan]
RESOLUTION: publish a LCWD of the Proximity Events spec
11:41:28 [bryan]
fjh: it will be after the F2F when pubrules has been checked etc
11:41:45 [fjh]
action: anssi to prepare Proximity LC draft and run through pubrules
11:41:45 [trackbot]
Created ACTION-587 - Prepare Proximity LC draft and run through pubrules [on Anssi Kostiainen - due 2012-11-08].
11:42:11 [fjh]
action: fjh to review exclusion period for Ambient light
11:42:11 [trackbot]
Created ACTION-588 - Review exclusion period for Ambient light [on Frederick Hirsch - due 2012-11-08].
11:42:52 [Josh_Soref]
RRSAgent, draft minutes
11:42:52 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
11:43:11 [bryan]
fjh: re Ambient Light Events, we should be ready for last call
11:44:12 [fjh]
action: fjh to send CfC for Last Call of Ambient Light Events
11:44:13 [trackbot]
Created ACTION-589 - Send CfC for Last Call of Ambient Light Events [on Frederick Hirsch - due 2012-11-08].
11:44:21 [Josh_Soref]
i/vibration and wrap/Topic: Vibration/
11:44:46 [Josh_Soref]
i/proximity and ambient light sensors/Topic: proximity and ambient light sensors/
11:44:53 [bryan]
topic: Network Information API
11:44:55 [Josh_Soref]
RRSAgent, draft minutes
11:44:55 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref
11:45:35 [bryan]
fjh: Network Information API was not shelved
11:47:03 [bryan]
break for lunch
11:47:14 [kenji]
kenji has left #dap
11:47:35 [smaug]
smaug has joined #dap
11:48:26 [giuseppe]
giuseppe has left #dap
11:48:37 [bryan]
returning at 1:45 PM
11:49:38 [glenn]
glenn has joined #dap
12:11:50 [smaug]
smaug has joined #dap
12:11:58 [Shinji]
Shinji has joined #dap
12:32:55 [jiro_]
jiro_ has joined #dap
12:33:21 [jiro_]
jiro_ has left #dap
12:33:46 [sungok_you]
sungok_you has joined #dap
12:34:19 [Cathy]
Cathy has joined #dap
12:35:46 [jcdufourd]
jcdufourd has joined #dap
12:41:06 [whyun]
whyun has joined #dap
12:41:23 [hta]
hta has joined #dap
12:42:02 [a12u]
a12u has joined #dap
12:42:30 [npdoty]
npdoty has joined #dap
12:46:21 [kensaku]
kensaku has joined #dap
12:47:17 [spoussa]
spoussa has joined #dap
12:48:04 [AnssiK]
AnssiK has joined #dap
12:50:36 [adrianba]
adrianba has joined #dap
12:50:50 [glenn]
glenn has joined #dap
12:50:52 [tomoyuki]
tomoyuki has joined #dap
12:51:20 [Yoshihiro]
Yoshihiro has joined #dap
12:51:23 [tpacbot]
tpacbot has joined #dap
12:51:41 [jgiraud]
jgiraud has joined #dap
12:52:02 [bjkim]
bjkim has joined #dap
12:53:00 [youenn]
youenn has joined #dap
12:53:52 [Milan_Patel]
Milan_Patel has joined #dap
12:54:23 [kenji]
kenji has joined #dap
12:54:36 [jfmoy]
jfmoy has joined #dap
12:55:09 [kinji_]
kinji_ has joined #dap
12:55:10 [timeless]
timeless has joined #dap
12:55:27 [timeless]
scribe: timeless
12:55:28 [fjh]
zakim, who is here?
12:55:28 [Zakim]
sorry, fjh, I don't know what conference this is
12:55:29 [shan]
shan has joined #dap
12:55:29 [Zakim]
On IRC I see timeless, kinji_, jfmoy, kenji, Milan_Patel, youenn, bjkim, jgiraud, tpacbot, Yoshihiro, tomoyuki, glenn, adrianba, AnssiK, spoussa, kensaku, npdoty, a12u, hta, whyun,
12:55:31 [nwidell]
nwidell has joined #dap
12:55:32 [Zakim]
... jcdufourd, Cathy, sungok_you, Shinji, smaug, Josh_Soref, richt
12:55:38 [fjh]
zakim, this will be DAP
12:55:39 [adrianba]
Present+ Adrian_Bateman
12:55:39 [Zakim]
I do not see a conference matching that name scheduled within the next hour, fjh
12:55:50 [jsoh]
jsoh has joined #dap
12:55:51 [SungOk_You__]
SungOk_You__ has joined #dap
12:55:51 [glenn]
glenn has left #dap
12:56:02 [geun_hyung]
geun_hyung has joined #dap
12:56:31 [Sylvain_Lalande]
Sylvain_Lalande has joined #dap
12:56:32 [Josh_Soref]
topic: Network Information
12:56:36 [adrianba]
ACTION-474?
12:56:36 [trackbot]
ACTION-474 -- Adrian Bateman to make a proposal for Network Information API -- due 2012-10-15 -- OPEN
12:56:36 [trackbot]
http://www.w3.org/2009/dap/track/actions/474
12:56:43 [Josh_Soref]
adrianba: i've had an outstanding action for a really long time
12:56:46 [Josh_Soref]
dom: one year
12:56:51 [GregBillock]
GregBillock has joined #dap
12:56:52 [Josh_Soref]
adrianba: bad news, i may not be closing it today
12:56:57 [Josh_Soref]
... but i'm making progress
12:57:03 [Hidetoshi]
Hidetoshi has joined #dap
12:57:04 [Josh_Soref]
... this is about making a proposal for a network information api
12:57:13 [Josh_Soref]
... there was some disagreement
12:57:26 [fjh]
http://www.w3.org/TR/2011/WD-netinfo-api-20110607/
12:57:29 [eduardo_fullea]
eduardo_fullea has joined #dap
12:57:30 [timeless]
... one about reason for using it
12:57:35 [timeless]
s/Josh_Soref/timeless/
12:57:36 [timeless]
s/Josh_Soref/timeless/
12:57:36 [timeless]
s/Josh_Soref/timeless/
12:57:37 [timeless]
s/Josh_Soref/timeless/
12:57:45 [timeless]
s/Josh_Soref/timeless/
12:57:46 [timeless]
s/Josh_Soref/timeless/
12:57:52 [timeless]
... then there was a concern about bandwidth
12:58:02 [timeless]
... and whether the right network would be selected
12:58:16 [timeless]
... there were concerns about bandwidth determination and power use to determine it
12:58:22 [jiro]
jiro has joined #dap
12:58:23 [timeless]
... W8 includes network info for applications
12:58:28 [darobin]
darobin has joined #dap
12:58:36 [timeless]
... what i want to talk about today is giving you an update of what we're thinking
12:58:53 [timeless]
... what we've heard from app developers
12:58:58 [timeless]
... it may be inconclusive
12:59:04 [timeless]
... the main reason for this seems to be "Bill Shock"
12:59:20 [timeless]
... customer being billed for
12:59:29 [timeless]
... amount of data being used
12:59:34 [timeless]
... what we'd like is for applications
12:59:36 [dom]
Zakim, list conferences
12:59:36 [Zakim]
I see WAI_Indie()3:00AM, SW_LDP()2:30AM, SEC_WASWG(TPACSES)6:00AM active
12:59:38 [Zakim]
also scheduled at this time are Team_Global(review)8:00AM, HTML_WG()4:00AM, WAI_WCAG()3:00AM, I18N_WG()6:00AM, UW_MBUI()8:00AM, UW_UWA()9:00AM, WF_TF()9:00AM, Team_(admin)08:00Z,
12:59:38 [Zakim]
... HTML_WG(HTML2)4:00AM
12:59:41 [timeless]
... to respect the kind of network
12:59:44 [timeless]
... and change their behavior
12:59:49 [Jungkee]
Jungkee has joined #dap
12:59:52 [timeless]
... this can be dealt w/ at two layers in the app stack
12:59:54 [Jungkee]
Present+ Jungkee_Song
13:00:00 [timeless]
... one is for the system to make appropriate changes based on the network
13:00:11 [timeless]
... for the UA to make changes based on the network characteristics
13:00:17 [timeless]
... network perf of your site-web app
13:00:18 [robint]
robint has joined #dap
13:00:21 [smaug]
smaug has joined #dap
13:00:24 [timeless]
... will be better because UA did intelligent things
13:00:25 [JonathanJ1]
JonathanJ1 has joined #DAP
13:00:31 [timeless]
... app dev doesn't need to change any of their things
13:00:34 [timeless]
... to get benefit
13:00:40 [timeless]
... choosing to not precache video
13:00:44 [giuseppe]
giuseppe has joined #dap
13:00:45 [jinhong]
jinhong has joined #dap
13:00:50 [timeless]
... from a <video> element until someone presses Play
13:00:55 [timeless]
... in an adaptive stream media content
13:01:03 [dom]
Zakim, room for 3 for 4hours?
13:01:03 [Zakim]
I don't understand your question, dom.
13:01:03 [timeless]
... it might be imposing a maximum on bandwidth for streaming
13:01:06 [timeless]
... in html
13:01:08 [dom]
Zakim, room for 3 for 4 hours?
13:01:08 [Zakim]
I don't understand your question, dom.
13:01:13 [timeless]
... we were talking about Responsive Images
13:01:23 [timeless]
... the browser might choose to download the smallest possible image for a page
13:01:25 [jalvinen]
jalvinen has joined #dap
13:01:26 [timeless]
... if that might use less data
13:01:28 [dnkim]
dnkim has joined #dap
13:01:28 [dom]
Zakim, room for 4 for 240 minutes?
13:01:29 [Zakim]
ok, dom; conference Team_(dap)13:01Z scheduled with code 26631 (CONF1) for 240 minutes until 1701Z
13:01:43 [timeless]
... this is us saying "we should try to design features into the open web platform that can be intelligent"
13:01:49 [timeless]
... so when we're designing features
13:01:58 [timeless]
... let's be thoughtful about how the UA could change behavior for a Metered network
13:02:02 [timeless]
... second is about APIs in this space
13:02:07 [Takahiro]
Takahiro has joined #dap
13:02:08 [timeless]
... for web application to do something intelligent
13:02:14 [dom]
Zakim, call salon_pasteur
13:02:14 [Zakim]
ok, dom; the call is being made
13:02:15 [Zakim]
Team_(dap)13:01Z has now started
13:02:16 [Zakim]
+Salon_pasteur
13:02:20 [bryan]
q+ to ask how does the UA know the network is metered?
13:02:21 [timeless]
... it knows what it's trying to acheive
13:02:23 [timeless]
... we've had feedback
13:02:26 [timeless]
q- Josh_Soref
13:02:28 [timeless]
queue=
13:02:38 [bryan]
q+ to ask how does the UA know the network is metered?
13:02:39 [timeless]
... we just want to provide the best experience to customers
13:02:39 [Zakim]
+ +1.781.266.aaaa
13:02:46 [timeless]
... we don't want to degrade the experience to customers
13:02:47 [Zakim]
- +1.781.266.aaaa
13:02:49 [Zakim]
-Salon_pasteur
13:02:49 [timeless]
... we don't really know
13:02:50 [Zakim]
Team_(dap)13:01Z has ended
13:02:50 [Zakim]
Attendees were Salon_pasteur, +1.781.266.aaaa
13:03:00 [timeless]
... for certain key, high volume, high value web applications
13:03:01 [dom]
Zakim, call salon_pasteur
13:03:01 [Zakim]
ok, dom; the call is being made
13:03:02 [Zakim]
Team_(dap)13:01Z has now started
13:03:03 [Zakim]
+Salon_pasteur
13:03:03 [timeless]
... they definitely want to
13:03:07 [Zakim]
+ +1.781.266.aaaa
13:03:11 [timeless]
... applications they leave open for a long time
13:03:15 [fjh]
zakim, aaaa is cathy
13:03:15 [Zakim]
+cathy; got it
13:03:16 [timeless]
... social networks, web email clients
13:03:18 [Cathy]
zakim, aaaa is me
13:03:18 [Zakim]
sorry, Cathy, I do not recognize a party named 'aaaa'
13:03:22 [timeless]
... developers of those apps want to do something
13:03:36 [timeless]
... am i supposed to be conserving bandwidth, or not
13:03:38 [fjh]
q?
13:03:44 [timeless]
... that's the primary thing they care about
13:03:46 [timeless]
... for w8
13:03:56 [timeless]
... a place where we've got the experience / information available
13:04:09 [timeless]
... we didn't include anything in the app requirements to be aware of metered networks
13:04:12 [timeless]
... it's purely up to them
13:04:19 [timeless]
... we have very few apps taking advantage of this right now
13:04:21 [timeless]
... there are 25
13:04:26 [timeless]
... written within MS that do use this
13:04:35 [timeless]
... considered to be an important part of the app
13:04:46 [timeless]
... related to the same scenarios as web sites
13:04:54 [Travis]
Travis has joined #dap
13:04:57 [timeless]
... long running applications that constantly talk to the network
13:04:59 [kotakagi]
kotakagi has joined #dap
13:05:03 [fjh]
rrsagent, generate minutes
13:05:03 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html fjh
13:05:07 [timeless]
... we have several MS owned web properties keen to take advantage of this as well
13:05:16 [timeless]
... Outlook Web Access / Latest release of Exchange
13:05:23 [timeless]
... it supports mail offline in IndexedDB
13:05:32 [timeless]
... downloads messages or maybe only headers
13:05:40 [kotakagi]
kotakagi has joined #dap
13:05:48 [timeless]
... commonly part of installed thick client applications
13:06:00 [timeless]
RRSAgent, draft minutes
13:06:00 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html timeless
13:06:08 [timeless]
... high value applications
13:06:15 [timeless]
... makes it different to figure out how to prioritize
13:06:35 [timeless]
... if it's only in IE, it's problematic
13:06:45 [richt]
q+
13:06:45 [timeless]
... from our research, i don't think we should write it off as a problem that doesn't exist
13:06:48 [timeless]
... that people don't want to solve
13:06:59 [timeless]
... but perhaps it isn't the highest priority thing to work on in the group
13:07:11 [timeless]
q+ to point to Web Perf/Nav Timing/work on http timing
13:07:19 [timeless]
q- timeless
13:07:23 [bryan]
q+ to ask how does the UA know the network is metered?
13:07:24 [timeless]
q+ Josh_Soref to point to Web Perf/Nav Timing/work on http timing
13:07:32 [timeless]
... as deployment incresaes
13:07:37 [timeless]
s/incresaes/increases/
13:07:42 [timeless]
... there will probably be more demand
13:07:47 [timeless]
... and we can look at this more highly
13:07:56 [timeless]
... interested to hear if people have heard the same/different things
13:08:03 [timeless]
fjh: i don't think Shelving is the right word
13:08:15 [timeless]
... shelving is "we want to do something different, but low priority"
13:08:27 [timeless]
adrianba: i think some of the concepts in the current proposals ARE WRONG
13:08:38 [mounir]
q+ to ask if keywords would be more interesting?
13:08:38 [timeless]
... i don't think trying to determine available bandwidth is useful
13:08:48 [timeless]
... trying to know if it's metered is useful
13:08:49 [timeless]
ack richt
13:08:52 [richt]
Opera on the Network Information API > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036116.html
13:08:59 [timeless]
richt: i agree with a lot of what adrianba is saying
13:09:13 [fjh]
rrsagent, generate minutes
13:09:13 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html fjh
13:09:13 [timeless]
... comments from jgraham
13:09:14 [dcheng3]
dcheng3 has joined #dap
13:09:19 [kawakami]
kawakami has joined #dap
13:09:21 [timeless]
... we have issues getting bandwidth numbers
13:09:28 [timeless]
... but what's at issue here is if it costs
13:09:34 [timeless]
... there's forking if you get Bandwidth info
13:09:40 [timeless]
... Mobile v Real web again
13:09:46 [timeless]
... uses are Streaming the right video
13:09:53 [timeless]
... it's not fork the resources based on bandwidth
13:09:59 [timeless]
... there's some UCs here we want to solve
13:10:04 [timeless]
... but this approach is not optimal
13:10:12 [fwtnb]
fwtnb has joined #dap
13:10:12 [timeless]
... the implementations aren't great
13:10:19 [timeless]
... they're sort of hard coded, we could change it to get it right
13:10:24 [timeless]
... but we haven't got what it takes now
13:10:36 [seo]
seo has joined #dap
13:10:41 [timeless]
... I don't think Opera plans to implement this anytime soon
13:10:42 [jiro]
jiro has joined #dap
13:10:51 [fjh]
q?
13:10:59 [timeless]
... we don't have to get bandwidth
13:11:05 [timeless]
... right now we're reporting back to the developer
13:11:14 [timeless]
... maybe we can report to the UA what it wants/needs
13:11:19 [timeless]
... that'd be more privacy preserving
13:11:20 [timeless]
ack bryan
13:11:20 [Zakim]
bryan, you wanted to ask how does the UA know the network is metered?
13:11:30 [timeless]
bryan: if bandwidth calculation isn't worth the effort
13:11:37 [timeless]
... and primary UC is "is metered?"
13:11:47 [timeless]
... how does the device know the connection is metered?
13:11:57 [richt]
s/it's not fork the resources based on bandwidth/it's not fork the user experience based on bandwidth/
13:12:07 [timeless]
adrianba: we in windows, we have Network Configuration that understands the network we're connecting to
13:12:13 [timeless]
... the network is registered as a metered network
13:12:16 [timeless]
bryan: how?
13:12:24 [timeless]
adrianba: if i'm exporting a connection to a 4G network
13:12:32 [timeless]
... that connection has associated billing characteristics
13:12:36 [timeless]
bryan: how?
13:12:40 [timeless]
... through what specification
13:12:45 [timeless]
adrianba: this is a windows feature
13:13:01 [timeless]
bryan: this doesn't seem like an interoperable thing today
13:13:25 [timeless]
adrianba: how that gets configured to the device is out of scope
13:13:30 [timeless]
... i don't believe it's in scope for this WG
13:13:41 [timeless]
... happy to have that conversation about standardization, but not here
13:13:45 [shige_]
shige_ has joined #dap
13:13:55 [timeless]
bryan: just is that a valid argument for shelving
13:13:57 [gmandyam]
+q
13:14:03 [timeless]
s/+q/q+/G
13:14:24 [timeless]
adrianba: why can't every UA have a config option to say if it's metered?
13:14:25 [sunghan]
sunghan has joined #dap
13:14:26 [leetv2]
leetv2 has joined #dap
13:14:29 [timeless]
bryan: users don't know ?
13:14:32 [timeless]
... number of reasons
13:14:49 [timeless]
... primary driver is to save money
13:14:57 [timeless]
... i'd say from our perspective, as a service provider
13:15:05 [timeless]
... facilitating more effective use of network resources
13:15:12 [timeless]
... probably a more important use of an api
13:15:18 [timeless]
... we'd like to take advantage of WiFi
13:15:22 [timeless]
... without knowing that
13:15:29 [timeless]
... we don't have any way for apps to make a decision
13:15:46 [timeless]
... how could an app indicate to a UA the type of network they'd prefer for a particular network to be retrieved?
13:15:49 [JonathanJ1]
rrsagent, draft minutes
13:15:49 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html JonathanJ1
13:16:00 [timeless]
... leaving all decisions to UA/connection manager is problematic
13:16:07 [timeless]
... seems to be a gap in understanding true needs of an application
13:16:11 [timeless]
... content for particular resource
13:16:16 [timeless]
... and what would benefit a UA
13:16:17 [fjh]
q+
13:16:24 [timeless]
... metering isn't the only UC
13:16:36 [timeless]
ack me
13:16:44 [timeless]
ack Josh_Soref
13:16:44 [Zakim]
Josh_Soref, you wanted to point to Web Perf/Nav Timing/work on http timing
13:17:30 [fjh]
josh_soref: to deal with bandwidth or source of information can look to web performance wg to deal with this
13:18:10 [fjh]
josh_soref: network performance will not just depend on network, could depend on server, country it is etc
13:18:18 [fjh]
josh_soref: not every network is metered
13:18:31 [fjh]
josh_soref: agree with what adrian has said
13:18:54 [fjh]
josh_soref: user agents improve since ???
13:19:13 [seo]
rss generate minute
13:19:18 [fjh]
s/???/as they can get this information/
13:19:28 [bryan]
you may know the overall plan that you have, but knowing where you are in that plan in the current billing cycle is likely impossibe
13:19:32 [fjh]
josh_soref: can tell if on wifi or cellular by using DNS
13:19:45 [fjh]
dom: who do you know by DNS
13:19:56 [fjh]
josh_soref: DNS record for phone will say network
13:20:12 [fjh]
josh_soref: reverse DNS lookup gives different host domain
13:20:26 [fjh]
dom: worldwide?
13:20:30 [fjh]
josh_soref: improvements needed
13:20:31 [bryan]
is the DNS approach a standard or enforced?
13:20:42 [fjh]
s/needed/needed to some network providers
13:20:51 [adrianba]
q?
13:20:58 [fjh]
s/needed/needed to some network providers/
13:21:23 [bryan]
so the UA needs to use the DNS protocol to know?
13:21:24 [claudio]
claudio has joined #dap
13:21:27 [fjh]
q?
13:21:29 [fjh]
ack mounir
13:21:29 [Zakim]
mounir, you wanted to ask if keywords would be more interesting?
13:21:39 [timeless]
Josh_Soref: no, the server side can do the DNS lookup
13:21:52 [bryan]
how does the UA know that the app wants a specific content delivered via WiFi?
13:22:02 [timeless]
mounir: about type
13:22:07 [timeless]
... i don't think we should show that for privacy reasons
13:22:13 [timeless]
... it adds bits of finger printing
13:22:16 [timeless]
... it helps tracking people
13:22:23 [timeless]
... you can try to guess where they are
13:22:34 [timeless]
... i don't think there's a real UC for knowing the type
13:22:37 [timeless]
... most of the time
13:22:46 [timeless]
... "we want wifi" because "we want fast network"
13:22:54 [timeless]
... they don't really care if it's wifi or 4g or cable
13:22:56 [timeless]
... they want fast
13:22:57 [bryan]
re type, josh just said that this is easily discoverable via DNS, so avoiding providing this information locally provides no additional privacy value
13:23:04 [timeless]
... about metered, as Josh_Soref said
13:23:09 [timeless]
... it's hard to do right now
13:23:13 [timeless]
... but it's easy to improve
13:23:18 [timeless]
... if we have a Spec for that
13:23:22 [timeless]
... it's easy to improve later
13:23:30 [timeless]
... as MS is doing to push carriers
13:23:35 [timeless]
... and about bandwidth
13:23:40 [timeless]
... we may still have UC for that
13:23:51 [timeless]
... i think some apps might want to save bandwidth if you have low battery
13:23:57 [timeless]
... regarding UX it might be better
13:24:05 [timeless]
... i wonder if checking battery to something accurate
13:24:09 [timeless]
... to KB
13:24:13 [timeless]
... to track if you're slow or fast
13:24:17 [timeless]
... might solve some issues
13:24:20 [timeless]
... and keep the feature
13:24:21 [bryan]
so how easy to improve? as a deployer of device management (the only feasible approach to get metering info as a standard), I can tell you that even static info provisioning is complex
13:24:25 [timeless]
dom: what's the UC for bandwidth?
13:24:35 [timeless]
... adrianba said research showed
13:24:39 [timeless]
... no real use for this
13:24:42 [timeless]
... do you have concrete UC
13:24:49 [timeless]
... or know of real apps that would use it?
13:24:58 [timeless]
mounir: i don't have an example of an extension using that
13:25:02 [timeless]
... we could make up one
13:25:06 [bryan]
getting dynamic metering info (where you are in the billing cycle, or how specific resource would affect your plan) is even more difficult
13:25:13 [timeless]
... but for Battery API, there's a argument of no UC for it
13:25:18 [AnssiK]
q?
13:25:23 [timeless]
... but if i don't have such a feature, then.. how can you use it?
13:25:27 [bryan]
q+
13:25:29 [timeless]
... it seems like a chicken-egg problem
13:25:39 [timeless]
... i'd appreciate if my email client doesn't fetch body on low bandwidth
13:26:13 [timeless]
q+ Josh_Soref to note that bandwidth has little relation to power use, if you get the data in a single packet, or stream of consecutive packets
13:26:21 [timeless]
dom: does firefox os have this?
13:26:24 [timeless]
mounir: no
13:26:32 [timeless]
sicking: when we started this work
13:26:36 [timeless]
... we spoke to PhoneGap
13:26:41 [timeless]
... and asked what apis people asked about
13:26:44 [bryan]
josh that is not correct, small packet transmission has a much different power profile
13:26:51 [timeless]
... they said a big request was for Edge/WiFi/3G
13:27:02 [timeless]
... they had a bunch of apps that wanted to know
13:27:14 [timeless]
... if they had a high bandwidth video and a bad connection, they knew it was going to fail
13:27:22 [AnssiK]
PhoneGap's Connection API: http://docs.phonegap.com/en/edge/cordova_connection_connection.md.html#Connection
13:27:25 [timeless]
... their UC was to avoid initiating a network connection if it was going to fail
13:27:36 [spoussa]
Present+ Sakari_Poussa
13:27:39 [timeless]
... if you want to avoid doing connection, you've already lost
13:27:45 [AnssiK]
[PhoneGap aka Apache Cordova]
13:27:48 [timeless]
... no particularly strong UCs for WiFi v. Ethernet
13:27:53 [timeless]
.. not even 3G v. WiFi
13:27:57 [timeless]
s/../.../
13:28:02 [timeless]
... but Edge v. Other stuff
13:28:07 [timeless]
... same thing w/ online v. offline
13:28:11 [timeless]
... you can argue it's useless
13:28:24 [timeless]
... we still have it
13:28:24 [fjh]
q?
13:28:32 [timeless]
Josh_Soref: because you can't get rid of it
13:28:45 [timeless]
dom: just relating what adrianba said
13:28:50 [timeless]
mounir: adding Type
13:28:56 [timeless]
... some people seem to want it back
13:28:59 [timeless]
... before my proposal
13:29:06 [timeless]
... there were property name for connection
13:29:11 [timeless]
... "If 2G or 3G, we're slow"
13:29:17 [timeless]
... i doubt 3G is "always slow"
13:29:22 [timeless]
... wifi can be way more slow than 3G
13:29:27 [timeless]
... which helps for UC
13:29:31 [timeless]
... adding slow connection
13:29:36 [timeless]
... a better UC for bandwidth is Games
13:29:39 [timeless]
... if you're playing games
13:29:45 [mounir]
q?
13:29:47 [timeless]
... you may want low bandwidth
13:29:50 [timeless]
ack gmandyam
13:29:55 [timeless]
present+ Jonas_Sicking
13:30:05 [timeless]
gmandyam: talking w/ a Qualcomm hat on
13:30:10 [timeless]
... we do know there are many situations
13:30:21 [timeless]
... just because you have WiFi, doesn't mean you're getting an increased throughput
13:30:28 [timeless]
... while you're staying in the same location
13:30:36 [timeless]
... developers making a decision based on that
13:30:43 [timeless]
... are not always going to make the right decision
13:30:44 [timeless]
Josh_Soref: +1
13:31:00 [timeless]
gmandyam: even though bandwidth estimation isn't passed
13:31:07 [timeless]
... at least on a handheld device
13:31:12 [timeless]
... if it isn't matching the modem estimate
13:31:14 [timeless]
... it isn't good
13:31:24 [bryan]
"not always making the right decision" is certainly true, but is that the objective, or is it to address the majority of use cases in which it would be the right decision?
13:31:24 [timeless]
... it's a MUST that browser vendors do this with the chipset vendors
13:31:37 [timeless]
... if they're not able to do it, it isn't a worthwhile feature
13:31:45 [timeless]
... OMA is actually looking into similar activity
13:31:47 [GregBillock]
GregBillock has joined #dap
13:31:52 [timeless]
... they just standardized a Connection Manager API
13:31:53 [fjh]
q?
13:31:57 [timeless]
... they're talking about a JS API
13:32:01 [timeless]
... a readonly API
13:32:10 [timeless]
... we doing it, they doing it, will cause confusion
13:32:16 [timeless]
... like to see that resolved
13:32:18 [timeless]
ack fjh
13:32:24 [timeless]
fjh: [ adrianba left ]
13:32:27 [kinji_]
kinji_ has joined #dap
13:32:34 [timeless]
... need to make time for web activities/intents
13:32:40 [timeless]
... do we shelve/discuss?
13:32:50 [timeless]
... after bryan + Josh_Soref, maybe straw poll?
13:32:58 [timeless]
ack bryan
13:33:11 [timeless]
bryan: key points
13:33:18 [timeless]
... we shouldn't let the perfect be the enemy of the goood
13:33:21 [timeless]
s/goood/good/
13:33:26 [timeless]
... this is definitely a valuable feature
13:33:35 [dom]
[my sense is that there is rough consensus that "metered" is a useful feature; bandwidth/type is more controversial at this time]
13:33:39 [timeless]
... network operators want apps to be smarter
13:33:42 [dom]
q?
13:33:48 [timeless]
... they want apps to have a consistent experience
13:33:55 [fjh]
q+
13:33:58 [timeless]
... if not addressed in W3C, it'll be addressed somewhere
13:34:04 [timeless]
... i'd prefer the open web to develop it
13:34:14 [timeless]
... connectional information is important
13:34:22 [timeless]
... rather than telling the App what it can know
13:34:33 [timeless]
... if the app could tell the platform "this is what i would like"
13:34:40 [timeless]
... "deliver this over WiFi"
13:35:02 [timeless]
... dropping everything because some things could be done
13:35:05 [timeless]
ack Josh_Soref
13:35:05 [Zakim]
Josh_Soref, you wanted to note that bandwidth has little relation to power use, if you get the data in a single packet, or stream of consecutive packets
13:35:27 [dom]
[I think the "deliver this over WiFI network" would be in scope for an entirely different API, which I can't assess from the top of my head whether it would in scope for DAP]
13:35:59 [fjh]
josh_soref: if you receive multiple packets at one time versus individually power usage will be less
13:36:01 [alexandremorgaut]
alexandremorgaut has joined #dap
13:36:29 [fjh]
josh_soref: thus shouldn't second guess efficiency of implementation and if apps try to manage this then it might not work so well
13:36:43 [fjh]
s/be less/be less, if the radio only turns on once/
13:37:28 [fjh]
josh_soref: deliver over unmetered can be in source set (?) specification
13:37:41 [fjh]
josh_soref: agreeing with adrian here
13:37:48 [fjh]
s/source/src/
13:38:06 [dom]
(@srcset is a very specific and limited use case for metered)
13:38:18 [nwidell]
q+
13:38:27 [timeless]
richt: progressive enhancement
13:38:41 [timeless]
... by giving web page, we're assuming web pages to know what to do with it
13:38:49 [timeless]
... by giving web page the information
13:39:01 [timeless]
... we're letting the pages create a 2 tiered scenario
13:39:07 [fjh]
s/src set/srcset/
13:39:09 [timeless]
... we want to be able to let metered UC handle
13:39:17 [timeless]
... it doesn't have to be in JS
13:39:22 [timeless]
... it could be in HTTP headers
13:39:26 [timeless]
... it could be a button in UA
13:39:33 [bryan]
leaving apps with no usable contextual info also creates a two-tier situation, in which developers are assumed to be stupid and browsers assumed to be all-intelligent
13:39:36 [timeless]
... "turtle" throttle from this point onwards
13:39:41 [timeless]
... there's lots of different ways
13:39:49 [timeless]
... i don't think we're at a solution
13:39:53 [timeless]
Zakim, close the queue
13:39:54 [Zakim]
ok, timeless, the speaker queue is closed
13:40:00 [timeless]
q?
13:40:02 [timeless]
ack nwidell
13:40:06 [plinss]
plinss has joined #dap
13:40:16 [timeless]
nwidell: after this, i think we need a better understanding of UCs
13:40:20 [timeless]
... there's Bill Shock
13:40:21 [Suresh]
Suresh has joined #dap
13:40:26 [timeless]
... bandwidth Adaptation
13:40:33 [timeless]
... which can be done server/client side
13:40:39 [fjh]
potential action on proponents of use of network information API to document APIs
13:40:45 [Suresh]
Present+Suresh_Chitturi
13:40:48 [timeless]
... i don't think we should shelve it right away, get UCs first
13:40:51 [timeless]
ack fjh
13:40:58 [timeless]
fjh: i don't think we should shelve it right away
13:41:07 [youenn]
youenn has joined #dap
13:41:08 [timeless]
... i think we should get UCs documented
13:41:22 [timeless]
... i think on the home page we could put a notes saying this group is still reviewing spec
13:41:34 [Suresh]
Suresh has joined #dap
13:41:34 [timeless]
mounir: we should make clear there's two specifications
13:41:39 [timeless]
... people get confused
13:41:47 [timeless]
AnssiK: /tr doc is out of date
13:41:50 [timeless]
dom: we should update /tr
13:41:56 [timeless]
mounir: i can do that
13:42:05 [timeless]
dom: updated working draft saying we're exploring the space
13:42:09 [timeless]
... bandwidth has Issue
13:42:14 [timeless]
... metered seems interesting
13:42:17 [timeless]
... putting UC in this
13:42:22 [timeless]
... i'm happy to put note
13:42:31 [timeless]
mounir: i can add UC section to spec
13:42:39 [timeless]
jcdufourd: please
13:42:53 [timeless]
fjh: published TR is out of date
13:43:01 [timeless]
... best way to publish updated WD
13:43:06 [timeless]
... create updated WD, publish, update SoD
13:43:12 [timeless]
... make clear it's under discussion
13:43:16 [timeless]
... updating UCs
13:43:24 [timeless]
... i'll give an action to do that to mounir
13:43:29 [timeless]
... dom can help
13:43:39 [timeless]
... and we agree to publish updated WD
13:43:47 [timeless]
... any objection to publish updated WD
13:43:52 [richt]
The use cases are important but we might be able to find a better solution.
13:43:54 [richt]
e.g. provide a 'turtle' icon in the UA. The user can click it when they are in a low-bandwidth network or on a metered network (or the browser can set it based on network changes itself). Then the UA sends an indicator of this setting in a HTTP header for subsequent requests until the user/browser switches it off.
13:43:58 [timeless]
RESOLUTION: Publish updated WD of network information
13:44:12 [timeless]
fjh: nothing else required for publication?
13:44:21 [timeless]
dom: people may want to see draft before
13:44:23 [fjh]
ACTION: mounir to prepare updated WD of network information with updated status, including addition of use cases
13:44:23 [trackbot]
Created ACTION-590 - Prepare updated WD of network information with updated status, including addition of use cases [on Mounir Lamouri - due 2012-11-08].
13:44:34 [fjh]
we will share draft in group for review before publication
13:44:44 [timeless]
dom: nwidell are you offering to help w/ UCs?
13:44:47 [timeless]
q?
13:44:55 [timeless]
Zakim, open the queue
13:44:55 [Zakim]
ok, timeless, the speaker queue is open
13:45:01 [fjh]
nwidell: yes will help with use cases
13:45:12 [Claes]
Claes has joined #dap
13:45:14 [timeless]
dom: don't be blinded by solution, focus on documenting problems
13:45:28 [timeless]
fjh: mounir, when can you update the draft?
13:45:32 [timeless]
mounir: within a month?
13:45:48 [timeless]
Topic: Web Intents/Web Activities
13:46:06 [timeless]
fjh: unfortunately, my plane was delayed by #Sandy
13:46:20 [timeless]
... GregBillock, i'd like to go through the issues
13:46:25 [timeless]
... understand web activities
13:46:33 [timeless]
... understand fundamental differences
13:46:41 [timeless]
... figure out what group wants to do?
13:46:45 [timeless]
... go from there?
13:47:13 [timeless]
GregBillock: current Chrome impl... i could show again
13:47:16 [timeless]
... it takes time
13:47:24 [timeless]
... current state, it's behind a flag in Chrome 24
13:47:38 [timeless]
... you go to chrome://flags and enable
13:47:44 [timeless]
... web intents from there
13:47:51 [timeless]
... implementation, mostly UI issues
13:47:55 [timeless]
... they're significant enough
13:48:16 [timeless]
... they're potentially needing api issues
13:50:17 [timeless]
... there are different dispositions for Web Intents services
13:50:24 [timeless]
... one is to render inline on top of the existing invoking tab
13:50:39 [timeless]
... kind of the experience -- tab modal dialog showing service
13:50:47 [timeless]
... backed by browser, overlaps location bar a bit
13:51:01 [timeless]
... you can tell it's a different surface than the original tab service
13:51:08 [timeless]
... you're still in the same task context as it were
13:51:16 [timeless]
... nice because it's related to what you were doing
13:51:27 [timeless]
... but it's a bit more difficult to adapt existing web apps to conform to that
13:51:34 [timeless]
... we decided to have a window disposition
13:51:42 [timeless]
... basically multiple tabs working on the same intent
13:51:51 [timeless]
... difficulty is letting user know this is what's going on
13:51:57 [timeless]
... couple of edge cases
13:52:05 [timeless]
... imagine editing a document from one tab
13:52:09 [timeless]
... if you close that
13:52:19 [timeless]
... and editor doesn't have a way to persist your changes, you can lose them
13:52:27 [timeless]
... we have a general concern
13:52:36 [timeless]
... if user isn't comfortable using tabbed browsing
13:52:45 [timeless]
... they might not understand this two tab thing
13:52:52 [timeless]
... the other one i talked about yesterday
13:52:58 [timeless]
... is the issue...
13:53:05 [timeless]
... initially we imagined the Service Picker
13:53:15 [timeless]
... we didn't want to expose what the situation was w/ installed services
13:53:28 [timeless]
... we wanted to leave open for the browser to let the user discover new services in the picker dialog
13:53:37 [timeless]
... that's worked out a lot less well than we thought they would
13:53:45 [timeless]
... users are a lot less comfortable with extensions
13:53:49 [timeless]
... don't understand what's offered
13:53:58 [timeless]
... the workflow w/ 4 steps deep install + authenticating
13:54:06 [timeless]
... it interrupts flow= bad experience
13:54:15 [fjh]
zakim, who is here?
13:54:15 [Zakim]
On the phone I see Salon_pasteur, cathy
13:54:16 [Zakim]
On IRC I see Claes, Suresh, youenn, plinss, alexandremorgaut, kinji_, GregBillock, claudio, leetv2, sunghan, shige_, jiro, fwtnb, kawakami, dcheng3, kotakagi, Takahiro, dnkim,
13:54:16 [Zakim]
... jalvinen, jinhong, giuseppe, JonathanJ1, robint, Jungkee, darobin
13:54:20 [timeless]
... that's a more significant challenge to the way we envisioned the feature working
13:54:36 [timeless]
... we may be after a way closer to the way hixie proposed on WhatWG
13:54:43 [timeless]
... closer to RPC/RPH
13:54:57 [timeless]
... semantically, users choose an application to fulfill service
13:55:04 [timeless]
... bypasses the need for showing service selection dialog
13:55:18 [timeless]
... that service selection process would have fewer problems
13:55:19 [timeless]
q?
13:55:23 [timeless]
... not saying we should do that
13:55:25 [timeless]
... but...
13:55:40 [timeless]
... the UI problems we came up w/ have an impact on how we view semantics / how we shape the api
13:55:44 [timeless]
... not sure that's the solution
13:55:55 [timeless]
... it's not just something the Chrome UI people will sit down and solve
13:55:59 [gmandyam]
q+
13:56:02 [timeless]
... but it affects the API level as well
13:56:13 [timeless]
... those are the main points
13:56:53 [robint]
robint has joined #dap
13:57:03 [timeless]
... a couple of things we've discussed in Intents list
13:57:11 [timeless]
... are making things closer to hixie's proposal
13:57:15 [timeless]
... and web activities
13:57:29 [timeless]
... changing window.intents delivery
13:57:40 [timeless]
... we assumed we'd always do intent delivery to a brand new context
13:57:50 [timeless]
... based on feedback from people who wanted to use the feature w/ an open application
13:58:04 [fjh]
q+
13:58:08 [fjh]
q-
13:58:11 [AnssiK]
q?
13:58:20 [timeless]
... even if we kept the existing spec
13:58:23 [timeless]
... we'd want to make changes like that
13:58:31 [timeless]
... using a message to do delivery instead of window.intent
13:58:43 [AnssiK]
q+
13:58:51 [timeless]
... and another thing is mirroring the RPC api for intents
13:59:08 [fjh]
ack gmandyam
13:59:17 [timeless]
gmandyam: i'm confused as to what you found in chrome
13:59:23 [timeless]
... how that impacts the normative text in the spec
13:59:29 [timeless]
... normative text doesn't get into UX
13:59:36 [timeless]
... also
13:59:45 [timeless]
... i haven't personally tested out explicit intents
13:59:52 [timeless]
... shouldn't that really be the fallback?
13:59:52 [JonathanJ1]
rrsagent, draft minutes
13:59:52 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html JonathanJ1
14:00:00 [massimo]
massimo has joined #dap
14:00:20 [timeless]
GregBillock: nothing in the normative text in the draft text reads on the UI in the browser chrome
14:00:23 [timeless]
... the way they feed back
14:00:53 [timeless]
... users should be using web intents because they're easy to use, easy to discover
14:01:00 [timeless]
... but they find the selector dialog confusing
14:01:06 [timeless]
... intimidating
14:01:19 [timeless]
... since that happened, we're considering perhaps not the same api
14:01:25 [timeless]
... if we change how we imagine connecting services
14:01:33 [timeless]
... we might have a different api that does that job
14:01:51 [timeless]
... it's possible we'd have a more navigation based solution
14:02:01 [timeless]
... if we have a mechanism that treats primitives of app construction
14:02:10 [timeless]
... the way they can be addressed in construction
14:02:17 [timeless]
... take an example
14:02:27 [timeless]
... i have an offline enabled app that supports a photo sharing site
14:02:34 [timeless]
... there's a button in it "please share this photo"
14:02:48 [timeless]
... you get a page in that app that does sharing to that service
14:03:04 [timeless]
... but the way you get to that is through a navigation transition
14:03:11 [fjh]
q+
14:03:14 [timeless]
... it could be a different api
14:03:44 [fjh]
q-
14:03:47 [timeless]
gmandyam: seems like it's part of a broader problem
14:03:54 [fjh]
q+ to ask about privacy and user interaction
14:03:56 [timeless]
... part of it is a discomfort with web stores in general
14:04:07 [timeless]
... which is part of why i think it's a mistake to consider modifying the proposal
14:04:35 [timeless]
GregBillock: there are some who'd rather things closer to bookmarks than a web store
14:04:50 [bryan]
q+ to ask what info suggests users are uncomfortable with web stores
14:05:02 [timeless]
... perhaps goes to sysapps
14:05:05 [timeless]
... think of what the right solution is
14:05:15 [timeless]
gmandyam: while we wait for better user acceptance of web stores
14:05:24 [timeless]
... we should make sure explicit intents is properly implemented
14:05:42 [timeless]
GregBillock: explicit intents
14:05:47 [timeless]
... is an important ingredient
14:05:51 [timeless]
... it wasn't there at first
14:06:04 [timeless]
... it was one of the things that jumped out of this
14:06:30 [timeless]
... a lot of people saw intents as important for transitions within their own applications (beyond just cross app)
14:06:33 [timeless]
... i agree that's important
14:06:47 [timeless]
... direct invocation
14:06:53 [hta]
hta has joined #dap
14:07:03 [timeless]
... -- web apps that are composed of elements that can be linked to
14:07:18 [timeless]
... my best guess is that a navigational metaphor is the best way to think of
14:07:24 [Claes]
q+
14:07:28 [timeless]
... just an intuition
14:07:31 [timeless]
ack AnssiK
14:07:38 [fjh]
q?
14:07:55 [timeless]
AnssiK: have you prototyped window-disposition in small phones?
14:08:01 [timeless]
... in small screens, it just doesn't work
14:08:08 [timeless]
... it kind of works on big screen
14:08:13 [timeless]
... but for mobile, it seems awkward
14:08:20 [timeless]
GregBillock: good question
14:08:25 [timeless]
... we hadn't done any on small screens
14:08:33 [timeless]
... our idea for how that'd look
14:08:41 [timeless]
... if you look at Chrome on Android and how tabs are there
14:08:44 [timeless]
... you'd transition
14:08:54 [timeless]
... they'd be "tabs", but presented in a full screen
14:09:04 [timeless]
... just as all "tabs" are in Chrome for Android
14:09:11 [timeless]
... in some ways that's an easier UI to solve the problem
14:09:20 [timeless]
... in terms of confusing UI
14:09:30 [timeless]
... on a small screen, you don't have the same opportunity for confusion
14:09:35 [timeless]
... about what not to touch
14:09:43 [timeless]
... a small screen ends up being modal
14:09:54 [timeless]
... for users who don't care about mechanics about who's operating screen when
14:10:00 [timeless]
... it's always overlapped/inline
14:10:06 [timeless]
... those problems are "easier" to solve
14:10:23 [timeless]
... if anything, small screens were easier
14:10:30 [shoko_]
shoko_ has joined #dap
14:10:32 [timeless]
... the tricky worries come up w/ multiple tabs on larger screens
14:10:47 [timeless]
AnssiK: what's your message to developers relying on the current web intents api?
14:10:59 [timeless]
... developers get mad
14:11:14 [timeless]
GregBillock: we're going to post a message on WebIntents G+ group and discussion forum
14:11:21 [timeless]
... letting people know we're putting it behind a flag
14:11:30 [timeless]
... the implementation is limited to apps in the store
14:11:38 [timeless]
... so we have a fixed list of services to speak to
14:11:54 [timeless]
... not a lot of web content relying on the existing impl
14:12:05 [timeless]
... we experimented with Chrome
14:12:11 [kawakami]
kawakami has joined #dap
14:12:12 [timeless]
... and were finding workarounds internally
14:12:24 [fjh]
q?
14:12:27 [hta]
hta has joined #dap
14:12:29 [timeless]
... not sure about reaction of putting behind a flag
14:12:33 [timeless]
... it was vendor prefixed
14:12:40 [timeless]
... that's not something vendors understand
14:12:51 [timeless]
AnssiK: i wouldn't be surprised if it made headlines in HTML5Weekly
14:12:53 [timeless]
ack fjh
14:12:53 [Zakim]
fjh, you wanted to ask about privacy and user interaction
14:13:03 [timeless]
fjh: GregBillock, you said Usability testing
14:13:10 [timeless]
... showed they couldn't handle the selection
14:13:21 [timeless]
... but i thought that was what we used for privacy control
14:13:31 [timeless]
GregBillock: UI problems
14:13:35 [smaug]
smaug has joined #dap
14:13:40 [timeless]
... relying on UI to guide normative parts
14:13:41 [fjh]
ack fjh
14:13:43 [kotakagi]
kotakagi has joined #dap
14:14:19 [timeless]
... the thing we were talking about w/ Store model
14:14:26 [timeless]
... people decide to adopt a particular app
14:14:35 [timeless]
... probably because they know the vendor/institution
14:14:43 [timeless]
... and they invest agency in that app
14:14:49 [timeless]
... that bundles trust transactions
14:15:01 [timeless]
... once they decide to use an app
14:15:05 [timeless]
... they accept the permission bundle
14:15:18 [timeless]
... there are people eager to do that because it makes their browser experience better
14:15:25 [timeless]
... some don't understand what it means
14:15:31 [timeless]
... people can opt out
14:15:55 [timeless]
... We saw use of Selection for Discovery wasn't working as well as we expected
14:16:03 [timeless]
... it's long, involves authentication
14:16:07 [timeless]
... you lose track of where you were?
14:16:12 [timeless]
s/?//
14:16:20 [timeless]
... trying to use that capability to get this job done
14:16:25 [fjh]
q?
14:16:27 [fjh]
ack bryan
14:16:27 [Zakim]
bryan, you wanted to ask what info suggests users are uncomfortable with web stores
14:16:50 [timeless]
bryan: gmandyam mentioned users not adopting web stores
14:16:58 [timeless]
... what indication is there to users not adopting them?
14:17:02 [timeless]
gmandyam: i was asking that
14:17:12 [timeless]
... it seems like GregBillock confirmed that
14:17:13 [comus]
comus has joined #dap
14:17:18 [timeless]
... classic users with some confusion
14:17:30 [timeless]
... i agree w/ bryan, there's no Google Play version for Android today
14:17:34 [whyun]
whyun has joined #dap
14:17:46 [timeless]
... a large segment of users who can't use it
14:17:59 [timeless]
bryan: i see some people have developed a way to load extensions in their syste
14:18:03 [timeless]
s/syste/system/
14:18:10 [timeless]
... i don't see activity to build market
14:18:21 [timeless]
... it makes sense to simplify UX
14:18:31 [timeless]
... i'm wondering how the shift from the UI experience
14:18:36 [timeless]
... would affect discoverability
14:18:38 [timeless]
ack
14:18:39 [fjh]
ack claes
14:18:45 [timeless]
s/ack claes//
14:18:46 [timeless]
s/ack//
14:18:55 [timeless]
Claes: having 2 tabs, one for client, one for service
14:19:17 [timeless]
... what about just having the service application in the same tab as the client, just replacing the client application
14:19:24 [timeless]
... which means he can't close the client app
14:19:28 [timeless]
... other was about the picker
14:19:39 [timeless]
... as i see it, it isn't just about picking, but also trust
14:19:52 [massimowww]
massimowww has joined #dap
14:20:09 [timeless]
GregBillock: one possibility is to think about
14:20:18 [timeless]
... intent invocation is a navigation transition in the tab
14:20:26 [timeless]
... that's a fruitful way to think about this
14:20:48 [timeless]
... there's also a big implication to the api
14:20:53 [timeless]
... the current API isn't navigational
14:20:58 [timeless]
... there are a lot of exciting aspects
14:21:04 [fjh]
q?
14:21:06 [timeless]
... i'm not sure if we should model it as navigation
14:21:16 [timeless]
... those are the implications for normative part of spec
14:21:21 [timeless]
... if we want to go with a different api
14:21:52 [timeless]
... if a user frequently goes to Flickr
14:22:00 [timeless]
... that's a suggestion that they have a photo they're about to save
14:22:09 [timeless]
... if you visited Flickr 60 times in the past month
14:22:13 [timeless]
... that's at the top of the list
14:22:49 [timeless]
... a web site could say
14:23:02 [timeless]
... i want to use this site for Email, Photo Sharing, Saving Documents, Editing Pictures
14:23:08 [timeless]
... when that gets selected
14:23:17 [timeless]
... that changes the default
14:23:24 [timeless]
... the current experimental prototype
14:23:26 [timeless]
... in 24
14:24:28 [Takahiro]
Takahiro has joined #dap
14:24:43 [jalvinen]
jalvinen has left #dap
14:24:53 [fjh]
break until 4 pm (35 min)
14:25:06 [Zakim]
-cathy
14:29:24 [massimo]
massimo has joined #dap
14:29:41 [smaug]
smaug has joined #dap
14:36:19 [darobin]
darobin has joined #dap
14:37:19 [Alexandre_Morgaut]
Alexandre_Morgaut has joined #dap
14:38:26 [bjkim]
bjkim has joined #dap
14:41:24 [shan]
rrsagent, draft minutes
14:41:24 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html shan
14:42:20 [comus]
comus has joined #dap
14:45:00 [Hidetoshi]
Hidetoshi has joined #dap
14:54:51 [JonathanJ1]
JonathanJ1 has joined #DAP
14:55:47 [nwidell]
nwidell has joined #dap
14:56:21 [kinji_]
kinji_ has joined #dap
14:57:13 [hta]
hta has joined #dap
14:58:18 [tomoyuki]
tomoyuki has joined #dap
14:59:14 [shepazu]
shepazu has joined #dap
14:59:28 [nsakai_]
nsakai_ has joined #dap
15:01:48 [Takahiro]
Takahiro has joined #dap
15:02:22 [Takahiro]
Takahiro has joined #dap
15:04:17 [Yoshihiro]
Yoshihiro has left #dap
15:04:27 [adrianba]
adrianba has joined #dap
15:04:31 [darobin]
darobin has joined #dap
15:04:34 [jalvinen]
jalvinen has joined #dap
15:04:51 [tomoyuki_]
tomoyuki_ has joined #dap
15:08:13 [Yoshihiro_]
Yoshihiro_ has joined #dap
15:08:46 [Cathy]
Cathy has joined #dap
15:09:36 [GregBillock]
GregBillock has joined #dap
15:09:53 [fjh]
zakim, who is here?
15:09:53 [Zakim]
On the phone I see Salon_pasteur
15:09:54 [Zakim]
On IRC I see GregBillock, Cathy, Yoshihiro_, tomoyuki, jalvinen, darobin, adrianba, Takahiro, hta, kinji_, nwidell, JonathanJ1, comus, bjkim, Alexandre_Morgaut, smaug, whyun,
15:09:54 [Zakim]
... kotakagi, kawakami, shoko_, Claes, youenn, plinss, fwtnb, dnkim, giuseppe
15:11:00 [Zakim]
+Cathy_Chan
15:11:11 [timeless]
topic: Web Activities
15:11:26 [timeless]
mounir: should i show the api?
15:11:40 [mounir]
https://wiki.mozilla.org/WebAPI/WebActivities
15:11:44 [mounir]
http://lists.w3.org/Archives/Public/public-web-intents/2012Jun/0061.html
15:11:46 [dcheng3]
dcheng3 has joined #dap
15:12:12 [timeless]
mounir: a url for the api, and one explaining why
15:12:15 [a12u]
Present+ Hiroyuki_Aizu
15:12:16 [jiro]
jiro has joined #dap
15:12:23 [timeless]
... we had to do something that looked like web intents for Firefox OS
15:12:32 [timeless]
... we thought Web Intents wasn't the correct solution
15:12:37 [timeless]
... and we needed something fast
15:12:40 [timeless]
... it was close enough
15:12:43 [npdoty]
npdoty has joined #dap
15:12:44 [timeless]
... in my opinion
15:12:51 [timeless]
... one of the issues we had
15:12:58 [timeless]
... Web Intents in the current specification (as of June)
15:13:02 [timeless]
... allowed you to do a lot of stuff
15:13:07 [timeless]
... people were using it to do a lot of stuff
15:13:17 [timeless]
... APIs based on web intents was something we thought shouldn't happen
15:13:24 [timeless]
... if you want a good UI
15:13:27 [timeless]
... you need a constrained UC
15:13:35 [timeless]
... e.g. trying to Run a web Intent that shows nothing
15:13:40 [timeless]
... would be really hard to do
15:13:49 [timeless]
... we tried to restrict that
15:13:53 [timeless]
... Web Activities
15:14:05 [timeless]
... has to have a UI
15:14:10 [timeless]
... we assumed that the UI was clear
15:14:12 [timeless]
... in Firefox OS
15:14:18 [timeless]
... if there's an activity handler
15:14:24 [timeless]
... we show that App for the Activity
15:14:36 [timeless]
... if the activity is doing nothing, user says "what's this app doing" and stop using it
15:14:57 [timeless]
... that Web Intents allowed communication between App A and App B, we tried to prevent that
15:15:11 [timeless]
... in Activity, an Activity returns a value or not
15:15:20 [timeless]
... a UI issue we had
15:15:23 [timeless]
... a new activity
15:15:31 [timeless]
... that was expected to return a value, like Edit
15:15:36 [timeless]
... the UA would have to return that value
15:15:42 [noriya_]
noriya_ has joined #DAP
15:15:45 [timeless]
... if the value would never be returned, we should fire an error
15:15:55 [timeless]
... to know if the activity would return a value or not, we had to know that
15:16:07 [timeless]
... the boolean for returnValue... is for UI purposes
15:16:27 [Hidetoshi]
Hidetoshi has joined #dap
15:16:29 [timeless]
... we don't have a type attribute in ActivityOptions
15:16:33 [timeless]
... most don't need type
15:16:40 [timeless]
... it was confusing web developers
15:16:46 [timeless]
... if you create an SMS, what type do you pass?
15:16:55 [timeless]
... inventing new types doesn't make sense
15:17:00 [timeless]
... type has to be in the data object
15:17:18 [timeless]
... technical difference in how you create an activity
15:17:21 [Jungkee]
q+
15:17:26 [timeless]
... the Navigator bit isn't implemented yet
15:17:34 [timeless]
... Web Activity is only implemented for Apps in Firefox OS
15:17:42 [timeless]
... we found issues that are different than what the Chrome team found
15:17:57 [timeless]
... i was telling GregBillock , web activity is interesting for a web os permission thing
15:18:07 [timeless]
... if an app might want to send an sms, it might not want to ask for permissions
15:18:23 [timeless]
... Today, Firefox OS only allows builtin apps to send SMS
15:18:33 [timeless]
... for a trusted app to send an SMS, you have to use an activity (today)
15:18:39 [timeless]
... for permission, you call that actiivity
15:18:42 [timeless]
... we go to the SMS app UI
15:18:54 [timeless]
... so you might understand you're going to send an sms
15:19:00 [timeless]
... and you'd have to press the Send button
15:19:09 [fjh]
q+
15:19:09 [timeless]
... to avoid the user not being aware of sending the sms
15:19:19 [timeless]
... we need the App and Activity to follow this rule
15:19:26 [fjh]
zakim, who is here?
15:19:26 [Zakim]
On the phone I see Salon_pasteur, Cathy_Chan
15:19:27 [timeless]
... there were internally issues for this
15:19:28 [Zakim]
On IRC I see Hidetoshi, noriya_, npdoty, jiro, dcheng3, GregBillock, Cathy, Yoshihiro_, tomoyuki, jalvinen, darobin, adrianba, Takahiro, hta, kinji_, nwidell, JonathanJ1, comus,
15:19:28 [Zakim]
... bjkim, Alexandre_Morgaut, smaug, whyun, kotakagi, kawakami, shoko_
15:19:32 [timeless]
... for the Telephone activity
15:19:33 [robint]
robint has joined #dap
15:19:40 [timeless]
... having to press the Green call button
15:19:45 [timeless]
... for security reasons
15:19:59 [timeless]
... even if we put as much restriction we could, we still had to rely on apps to be good citizens
15:20:05 [timeless]
... even more if you give them permissions
15:20:09 [timeless]
... things we found
15:20:38 [timeless]
... GregBillock mentioned window.intent and switching to DOM Event
15:20:45 [timeless]
... for Firefox OS, we're using sendMessage()
15:20:49 [timeless]
... if you send a DOM Event
15:20:58 [timeless]
... making a process to add an activity
15:21:05 [timeless]
... the app might still be open, or might have closed
15:21:10 [timeless]
... i might need to run the app
15:21:16 [timeless]
... if i run the app, and want to send a dom event
15:21:21 [timeless]
... it has to be clear when to send the dom event
15:21:30 [timeless]
... otherwise if the app registers too late, it might miss it
15:21:36 [timeless]
... after load might take a long time
15:21:40 [timeless]
... it was a problem
15:21:46 [timeless]
... too-hard to solve using dom events
15:22:07 [timeless]
s/sendMessage()/System Messages/
15:22:17 [timeless]
... System Messages are like DOM Events
15:22:22 [timeless]
... or window.intent
15:22:22 [jfmoy]
jfmoy has joined #dap
15:22:25 [timeless]
... it's sent by the system
15:22:32 [timeless]
... if the target isn't awake, the system will wake it
15:22:38 [timeless]
... and those messages will be Queueds
15:22:40 [timeless]
s/ds/d/
15:22:49 [timeless]
... if there's no handler, they'll wait for the handler to come
15:22:55 [timeless]
... the app can check at any time during load
15:23:00 [timeless]
... so they can prepare the UI
15:23:08 [timeless]
... and then they can register for the system message
15:23:24 [claudio]
claudio has joined #dap
15:23:26 [timeless]
... when they return to the event loop, we'll call that handler as many time as message are waiting
15:23:47 [timeless]
Josh_Soref: is it a Queue or Stack?
15:23:51 [timeless]
sicking: it's a Queue
15:23:58 [timeless]
mounir: this mechanism is only for Firefox OS
15:24:02 [timeless]
... we will push that in Sys Apps
15:24:11 [timeless]
... we don't know if it will be for regular web content
15:24:22 [timeless]
... what we defined is how to register
15:24:28 [timeless]
... but we haven't implemented it
15:24:34 [timeless]
... we might just use system messages
15:24:46 [timeless]
... regarding Registration
15:24:53 [timeless]
... using Intent inside the body
15:25:01 [timeless]
... right now, Firefox OS just uses the App Manifest
15:25:07 [timeless]
... to register for Activities
15:25:12 [timeless]
... since that isn't for web content
15:25:18 [timeless]
... we haven't decided how to do that
15:25:32 [timeless]
... i'm not a fan of in the <body>, but inside the <head> is understood to be painful
15:25:37 [timeless]
q?
15:25:50 [dom]
ack Jungkee
15:25:55 [gmandyam]
+q
15:25:56 [sicking]
sicking has joined #dap
15:26:08 [timeless]
Jungkee: i'm working on two WebIntent specs
15:26:16 [timeless]
... delivering data from server side to client side
15:26:23 [timeless]
... trying to use two activities
15:26:31 [timeless]
... we have many UCs to deliver data from one to another
15:26:43 [timeless]
... in the Pick an Image from the mozilla wiki page
15:27:36 [Josh_Soref]
-> https://wiki.mozilla.org/WebAPI/WebActivities#Handle_an_activity_request Pick an Image
15:27:50 [sicking]
q+
15:28:00 [sicking]
q-
15:28:21 [timeless]
Jungkee: how do you pick an image if you don't have communication between receiving web app and service
15:28:29 [timeless]
... we want to allow application to application data delivery
15:28:40 [timeless]
... mounir 's explanation in web activities, they don't allow that kind of communication
15:28:46 [timeless]
... ?
15:28:55 [timeless]
mounir: we allow an activity to return a value
15:29:08 [timeless]
... we don't want to allow app A and app B to communicate for an unlimited time frame
15:29:24 [timeless]
... a return value activity in the browser is hard UI wise
15:29:29 [timeless]
... as soon as PostResult is done,
15:29:34 [timeless]
... the UI is simple
15:29:37 [timeless]
... for closing the activity
15:29:58 [timeless]
... if there might be more activity, we don't know how to handle the UI
15:30:03 [timeless]
... what to show is undefined
15:30:16 [timeless]
... there are UCs where people want a View activity for a TV
15:30:25 [timeless]
... and App A controls play-pause
15:30:34 [timeless]
... we think that could be solved w/ another API
15:30:44 [timeless]
... and not activities requiring UI
15:30:52 [timeless]
Jungkee: i understand activities from ui side
15:30:57 [timeless]
... about pick media intent
15:31:10 [timeless]
... have you tried pick media intent/pick contact intent?
15:31:20 [timeless]
... from service page, we're picking contact information/media files
15:31:27 [dom]
-> http://dvcs.w3.org/hg/dap/raw-file/tip/gallery/Overview.html Pick Media Intent
15:31:32 [timeless]
... those two specs are now using picking some data payload
15:31:36 [timeless]
... service to client side
15:31:40 [dom]
-> http://dvcs.w3.org/hg/dap/raw-file/tip/contacts/Overview.html Pick Contacts Intent
15:31:45 [timeless]
... in my opinion right now, we can't avoid some user interaction
15:31:52 [jcdufourd]
q+ on assumption that you can kill the service provider page as soon as it has returned a value
15:31:53 [timeless]
... the user interaction between the ui page/tab/window/inline
15:31:57 [timeless]
... to an application page
15:32:05 [timeless]
... that kind of activity is something that i'm thinking about
15:32:09 [timeless]
... we talked about the UC
15:32:18 [timeless]
... we've been working on it w/ some demos
15:32:20 [timeless]
... do you have opinions?
15:32:28 [timeless]
mounir: i'm not sure i understand
15:32:36 [timeless]
... what activities allow you to pick media files?
15:32:46 [timeless]
Jungkee: does it allow ui thing?
15:32:59 [timeless]
mounir: we want to prevent stuff happening in the background w/o UI
15:33:03 [timeless]
... we always want a UI
15:33:12 [timeless]
... if you have a pick activity handled by gallery
15:33:17 [timeless]
... you use pick, gallery handles it
15:33:19 [GregBillock]
GregBillock has joined #dap
15:33:22 [timeless]
... gallery appears, you interact
15:33:25 [GregBillock]
q+
15:33:25 [timeless]
... you pick, it returns
15:33:28 [timeless]
... gallery closes
15:33:47 [timeless]
mounir: we implement File Input like that
15:34:02 [timeless]
sicking: we use activities to exactly this flow in Firefox OS
15:34:04 [timeless]
... it is working
15:34:16 [timeless]
fjh: similar question about UI stuff
15:34:25 [timeless]
... in web intents, we use user interaction for privacy/involve user
15:34:31 [timeless]
... do you have interaction as part of it?
15:34:37 [timeless]
... examples don't seem to involve user
15:34:45 [npdoty]
ack fjh
15:34:46 [timeless]
... every web activity involves user
15:34:55 [timeless]
... have there been usability issues
15:35:00 [timeless]
... or does it fall out naturally?
15:35:04 [timeless]
... indication that it's usable?
15:35:13 [timeless]
... is usability a concern here?
15:35:17 [timeless]
q?
15:35:23 [timeless]
mounir: we always want a ui
15:35:25 [sicking]
q+
15:35:29 [timeless]
... it's displayed,
15:35:35 [timeless]
dom: does the work flow of Web Activities
15:35:40 [timeless]
... does it work for Users?
15:35:46 [timeless]
mounir: we had a different experience than chrome
15:35:52 [timeless]
... because we only used it for Firefox OS
15:35:59 [timeless]
... but the user experience is very similar to Android
15:36:06 [timeless]
... Android experience isn't awful w/ Intents
15:36:41 [timeless]
fjh: Web Intents lets you have access to resources anywhere
15:36:46 [timeless]
... not just on device
15:36:53 [npdoty]
is there documentation about why Mozilla is pursuing this only for Firefox OS? what are the reasons for not using this in Firefox for Android or on desktop?
15:36:54 [timeless]
... request needs some service
15:36:58 [timeless]
... is web activities just the device?
15:37:05 [timeless]
mounir: it's more broad, but right now it's just the device
15:37:10 [timeless]
... there is a registry
15:37:18 [timeless]
... of which apps can handle an activity
15:37:24 [timeless]
... but right now it's limited to installed apps
15:37:34 [timeless]
... if you visit flickr.com, we could add that
15:37:36 [npdoty]
ah, I see, so it's just that the registry handler is disabled for non-installed apps?
15:37:38 [timeless]
q?
15:37:57 [timeless]
ack gmandyam
15:38:05 [timeless]
gmandyam: afaict, when i compared specs side by side
15:38:13 [timeless]
... you aren't depending on Web Messaging
15:38:26 [timeless]
... you didn't want to have Ports, and keeping Ports open was difficult to manage
15:38:34 [timeless]
mounir: we don't use Web Messaging/Ports
15:38:39 [timeless]
... because it's hard to manage UI wise
15:38:46 [timeless]
... we'd be interested in pushing a discovery API
15:39:01 [timeless]
... to allow background services
15:39:35 [timeless]
gmandyam: since web activities works w/o a dependency on web messaging
15:39:43 [timeless]
... and most web intents don't leverage feature of web messaging
15:39:48 [timeless]
... why did we need web messaging?
15:40:04 [timeless]
... maybe it might be better to define intents w/o web messaging?
15:40:10 [timeless]
... until browsers better handle on this problem?
15:40:14 [fjh]
q?
15:40:17 [timeless]
GregBillock: i was going to talk about exactly that
15:40:28 [fjh]
ack GregBillock
15:40:30 [timeless]
... for Intents, the expected UC is that the structured clone doesn't have ports
15:40:36 [timeless]
... structured clone supports transferables
15:40:43 [timeless]
... but you need Ports to do some of that
15:40:54 [timeless]
... the argument for using structured clone is the same as it has always been
15:41:10 [timeless]
... if interapp communication supports structured clone, it's maximally supported
15:41:20 [timeless]
... you get blobs transferably
15:41:24 [timeless]
... but you can't transfer ports
15:41:34 [timeless]
... you get unpredictably about interaction between contexts
15:41:44 [timeless]
... the right path forward might be to forget structured clones
15:41:53 [timeless]
... we might only support a subset of structured clone
15:42:08 [timeless]
... the difficulties of port exchange are such that it's tempting to not do it
15:42:34 [timeless]
... we might use urls
15:42:40 [timeless]
... and a separate system for some of that
15:42:43 [timeless]
... richt may have an idea
15:42:51 [timeless]
... about Pick Media in Intents v. Activities
15:42:57 [timeless]
... i think it can be trivially over either
15:43:05 [timeless]
... same vocab for both
15:43:25 [timeless]
... some communication mechanism as opposed to more specific
15:43:35 [timeless]
... same problem as Get User Media and Media Pick
15:43:41 [timeless]
... in one, it's "please get me a contact"
15:43:49 [timeless]
... but the application you're talking to, needs some api
15:44:02 [timeless]
... it may use its own contact store (IndexedDB) or its own api over the api
15:44:11 [timeless]
... if there are contact repositories on the device
15:44:22 [timeless]
... there are UCs where you want more high level integration
15:44:30 [timeless]
... sometimes it's useful to have a low level integration api
15:44:37 [timeless]
... apps responsible for receiving it
15:44:44 [timeless]
... need a way to do, e.g. Get User Media
15:44:53 [timeless]
... i'm not sure that having high level means you don't need low level
15:44:57 [timeless]
... just different levels of abstraction
15:44:58 [timeless]
q?
15:44:58 [dom]
ack jcdufourd
15:44:59 [Zakim]
jcdufourd, you wanted to comment on assumption that you can kill the service provider page as soon as it has returned a value
15:45:04 [nwidell]
q+
15:45:16 [timeless]
jcdufourd: mounir, you said it isn't ok to pass a message channel as a return from a web activity?
15:45:28 [timeless]
... because you want to be able to kill the service provider when it returns?
15:45:36 [shepazutu]
shepazutu has joined #dap
15:45:40 [timeless]
mounir: no, it's because i want to know when i'm done w/ the activity
15:45:42 [timeless]
... for the ui
15:45:49 [timeless]
... otherwise we can't build a good ui
15:46:09 [timeless]
jcdufourd: what if you have multiple registrants for an activity?
15:46:15 [timeless]
... what they solved w/ a picker?
15:46:18 [dom]
q?
15:46:23 [timeless]
mounir: we have a similar UI
15:46:26 [timeless]
... i haven't seen it
15:46:36 [timeless]
... it should look like the Android UI
15:46:43 [timeless]
... to show activity handlers
15:46:48 [timeless]
... we have some security rules
15:46:58 [timeless]
... to prevent activities to register/be open for certain things
15:46:59 [fjh]
q?
15:47:06 [dom]
ack sicking
15:47:10 [timeless]
ack sicking
15:47:19 [timeless]
sicking: one thing we're cheating
15:47:33 [timeless]
... but because we're only solving on small screen devices
15:47:38 [timeless]
... Chrome is dealing w/ a browser UI
15:47:44 [timeless]
... tabs have a special meaning
15:47:51 [timeless]
... all independent, user is in full control
15:47:56 [timeless]
... all rendered "at the same time"
15:48:03 [timeless]
... we're solving in "you're only showing one app at a time"
15:48:11 [timeless]
... starting an activity replaces the other app
15:48:18 [timeless]
... leaving an app cancels an activity
15:48:24 [timeless]
... we didn't implement this for web pages
15:48:29 [timeless]
... because of UI issues
15:48:35 [timeless]
... a lot of experimenting needs to be done
15:48:43 [timeless]
... i don't think Activities v. Intents makes a lot of difference
15:48:45 [timeless]
q?
15:48:49 [timeless]
ack nwidell
15:49:03 [jcdufourd]
q+
15:49:10 [timeless]
nwidell: it sounds like there's technical difficulties to Ports
15:49:12 [timeless]
... long lived
15:49:17 [timeless]
... but by abstracting a lot of interaction parts
15:49:28 [timeless]
... keeping a clean interface between client+server
15:49:34 [timeless]
... we've discussed sensor UCs
15:49:43 [timeless]
... it's a way to connect sensors that may not always be available
15:49:57 [timeless]
... available through some kind of message protocol
15:49:59 [dom]
q+ to interest on background services
15:50:01 [timeless]
... if we remove ports
15:50:07 [timeless]
... we'll need to consider a replacement mechanism
15:50:10 [timeless]
... for long lived
15:50:20 [timeless]
ack jcdufourd
15:50:29 [trackbot]
trackbot has joined #dap
15:50:30 [timeless]
jcdufourd: re sicking
15:50:35 [timeless]
... this isn't implemented for web pages?
15:50:41 [timeless]
sicking: this is only implemented for Firefox OS
15:50:47 [timeless]
... for our Application Platform
15:50:51 [timeless]
... only Installed Applications
15:50:56 [Claes]
+1 for nwidell's comment
15:50:59 [timeless]
... can be handlers for Activities
15:51:07 [timeless]
... web pages can invoke a Pick Activity
15:51:11 [timeless]
... but it can't handle one
15:51:33 [timeless]
jcdufourd: you've implemented service providers in HTML/CSS/JS in a browser like context
15:51:42 [timeless]
sicking: i'm distinguishing Web Apps from Web Pages
15:51:47 [timeless]
jcdufourd: only in the context of small screens?
15:51:55 [timeless]
... is it applicable to the wider context of web intents?
15:52:00 [timeless]
sicking: it needs to be experimented with
15:52:10 [timeless]
... we'd have many of the same unsolved questions as Web Intents
15:52:15 [timeless]
... one issue is seeing two tabs rendered
15:52:31 [timeless]
... the first tab is still there
15:52:34 [timeless]
... you can switch between them
15:52:41 [timeless]
... user can open a new web page
15:52:46 [timeless]
... we'd have these problems in Activities
15:52:56 [timeless]
mounir: for us, there's only one App (shown at the same time)
15:53:03 [timeless]
... if an activity is handled of App A
15:53:07 [timeless]
... there's only one instance of App A
15:53:16 [npdoty]
the small screen is essentially modal
15:53:22 [timeless]
... if it were to be handled by Flickr.com, which window handles it?
15:53:24 [timeless]
... a new one?
15:53:27 [timeless]
q?
15:53:28 [timeless]
ack dom
15:53:28 [Zakim]
dom, you wanted to interest on background services
15:53:40 [timeless]
dom: thanks, that clarifies a lot of things to me
15:53:48 [timeless]
... i'm not clear if we can converge activities with intents
15:53:56 [timeless]
... not sure if we have hopes for solving the UI
15:54:00 [GregBillock]
GregBillock has joined #dap
15:54:19 [timeless]
... a separate background API could solve UCs that have been brought up
15:54:23 [timeless]
... i know there are UCs for this
15:54:31 [timeless]
... I know Web Intents was meant to solve this UC
15:54:36 [timeless]
... but it seems it isn't safe to assume that
15:54:45 [timeless]
... should we start forking Intents or,...
15:54:50 [timeless]
... to work on this set of UCs?
15:55:09 [timeless]
GregBillock: initially we called that Hidden Disposition
15:55:12 [timeless]
... like a Web Worker
15:55:19 [timeless]
... that could respond to Web Intent invocations with a result
15:55:25 [timeless]
... requiring no ui surface
15:55:33 [timeless]
... trying to think about how that'd work
15:55:38 [timeless]
... we didn't find a good UI solution for that
15:55:48 [timeless]
... there are definitely reasons it'd be nice to have
15:55:58 [timeless]
... we're not sure how to present that
15:56:12 [timeless]
... for installed apps, it's a bit easier to imagine how it's solved
15:56:17 [timeless]
... there's already a trust for that
15:56:26 [timeless]
... but for web content at large, it's frightening
15:56:36 [timeless]
... to imagine getting access to a sandbox without a task manager
15:56:42 [timeless]
... we haven't cracked that yet
15:56:47 [bryan]
+1 to starting discussion on a background service API
15:56:56 [timeless]
mounir: i drafted quickly an api for that
15:57:01 [timeless]
... we haven't implemented it
15:57:03 [timeless]
... and not soon
15:57:06 [timeless]
... if there's interest
15:57:15 [timeless]
dom: that would be a good idea
15:57:16 [bryan]
q+
15:57:21 [timeless]
... not sure about sooner or not
15:57:26 [timeless]
... getting ideas cannot hurt
15:57:39 [timeless]
... it might clarify information re: network discovery proposal
15:57:46 [timeless]
... how these fit/don't together
15:57:50 [timeless]
ack bryan
15:57:58 [timeless]
bryan: that proposal would be one we'd be interested in talking about
15:58:20 [timeless]
... in web & tv, there's interest in using IndexedDB as a filesystem
15:58:27 [timeless]
... but the restriction on origin is problematic
15:58:34 [timeless]
... on an opt in
15:58:42 [timeless]
... to faciliate a virtual file system for web apps
15:58:44 [timeless]
... could be nice
15:58:50 [fjh]
q?
15:58:59 [timeless]
richt: we'll talk about network service discovery tomorrow
15:59:05 [timeless]
... we've talked about ongoing services using urls
15:59:19 [timeless]
... we've looked at allowing a web page to advertise itself as a network service
15:59:25 [timeless]
... but a flag that it's only available on this device
15:59:35 [timeless]
... say for network, or only for device
15:59:40 [timeless]
... it's all client JS
15:59:42 [timeless]
... two tabs
15:59:48 [timeless]
... create background long running communication
15:59:52 [timeless]
... based on URL created by UA
16:00:03 [timeless]
... the URL allows HTTP semantics
16:00:09 [timeless]
... page dies, we can send timeouts
16:00:18 [timeless]
... part of HTTP stuff
16:00:36 [timeless]
... but also flicking a flag to allow other devices to connect
16:00:39 [timeless]
... it's exciting
16:00:48 [timeless]
fjh: thanks, this has been very helpful
16:01:05 [timeless]
... what can we do pragmatically
16:01:12 [timeless]
... GregBillock, you're still working on it?
16:01:24 [kotakagi]
kotakagi has joined #dap
16:01:24 [timeless]
... mounir, you have a non-contributed spec
16:01:37 [timeless]
... Jungkee mentioned looking at our pick spec
16:01:42 [timeless]
... you said it'd be straightforward
16:02:02 [timeless]
... sicking was saying the UI problem wasn't solved no matter what
16:02:04 [timeless]
... what should we do?
16:02:18 [ares]
ares has joined #dap
16:03:21 [timeless]
GregBillock: we could come up w/ ideas
16:03:25 [richt]
just one minute timeless? I'd be happy to.
16:03:35 [timeless]
... but it'd be hard to import into Chrome/Firefox UI process
16:03:36 [richt]
s/just one minute timeless? I'd be happy to.//
16:03:49 [timeless]
... it isn't a very satisfying message
16:03:52 [timeless]
fjh: it makes sense
16:04:14 [timeless]
... we want wide interop adoption
16:04:24 [timeless]
... will this outcome mean interop implementations?
16:04:40 [timeless]
GregBillock: that's the goal
16:04:59 [richt]
Scribe: richt
16:05:07 [dom]
scribenick: richt
16:05:16 [richt]
GregBillock: I think there is commitment there that we can work together on this.
16:05:30 [richt]
... the optimism is well-founded. It's an encouraging prognosis.
16:05:45 [richt]
mounir: I agree. Our goal is to have an interoperable implementation.
16:05:57 [richt]
... we don't want to stay inside walls.
16:06:12 [richt]
dom: So what are the next steps? actions?
16:06:20 [richt]
GregBillock: We're going to be talking for sure.
16:06:31 [richt]
... There are other profitable directions to think about.
16:06:32 [fjh]
q?
16:06:42 [richt]
... We need to think about some of the ideas like navigation.
16:06:54 [richt]
... Some of the things richt was talking about reminded me of that.
16:07:03 [richt]
... e.g. HTTP semantics.
16:07:27 [richt]
... I could be totally wrong about that direction but if someone is sitting on a great idea about how that will work in an instant way then we'd be excited to hear about it.
16:07:46 [richt]
dom: Another question. A lot of people have heard about Web Intents. We have a Working Draft.
16:07:59 [richt]
... Only very few will hear about the discussions we've had over the last few days.
16:08:13 [richt]
... What can we do with the existing draft to make it clear where we are at with this?
16:08:27 [richt]
GregBillock: It's on us (the draft editors) that current status is correctly reflected.
16:08:37 [richt]
... and the way to make progress here.
16:08:45 [richt]
... That is all going to be happening soon.
16:08:57 [richt]
... We wanted to talk in DAP about this stuff before we sent all that info out.
16:09:17 [richt]
... Make sure we're saying things that the WG is agreeing on.
16:09:42 [nwidell]
q+
16:09:53 [richt]
fjh: If GregBillock and mounir could discuss this soon then we could put out a collaboration announcement aka. making progress on this stuff.
16:10:10 [richt]
GregBillock: We've put our implementation behind a flag. There's still a lot of thinking and problem-solving going on
16:10:29 [richt]
... We'll see what the outcome will be here.
16:10:40 [richt]
... Part of that whole process will be based on discussion we have on the mailing list.
16:10:52 [fjh]
q?
16:11:17 [fjh]
ack nwidell
16:11:24 [richt]
nwidell: Require a clarification: Are we removing long-life connectivity from Web Intents?
16:11:36 [richt]
s/long-life/long-lived/
16:11:51 [richt]
fjh: Presume we wouldn't need another mailing list for this?
16:11:57 [richt]
dom: That's in scope for DAP
16:13:16 [richt]
fjh: What would happen to the work you're doing richt
16:13:40 [richt]
richt: We've been coming at this from a different angle...
16:14:07 [whyun]
whyun has joined #dap
16:14:12 [richt]
... We've realised we have a good opportunity to do long-lived background process stuff via the discovery spec with the addition of e.g. register functions.
16:14:27 [richt]
... we'll be talking about that soon and hope to add something to the spec there so there may be some overlap.
16:14:31 [fjh]
q?
16:14:59 [richt]
Topic: Agenda review
16:15:06 [richt]
fjh: I've updated the agenda for tomorrow.
16:15:21 [richt]
,,, Start time is currently 9am.
16:15:28 [timeless]
s/,,,/.../
16:15:53 [richt]
fjh: On request we're moving Network Service Discovery to the morning session.
16:16:02 [Cathy]
q+ about time for network discovery discussion
16:16:11 [richt]
... After lunch we'll be talking about signage, pick media and calendar.
16:16:15 [Cathy]
q+ to ask about time for network discovery discussion
16:16:25 [richt]
... We'll be briefly talking about Media Capture and Sensors.
16:16:28 [timeless]
/me looks like around 9am
16:16:43 [richt]
... We wanted to talk about CoreMob a little also.
16:16:52 [timeless]
s| /me looks like around 9am||
16:17:01 [richt]
dom: We have a few people in the room that are also involved in CoreMob.
16:17:49 [Hidetoshi]
Hidetoshi has joined #dap
16:17:59 [richt]
fjh: At the request of Cathy (due to TZ differences) could we move Network Service Discovery to just after lunch?
16:18:23 [npdoty]
I don't think lunch is served until 12:30
16:18:23 [richt]
... so 1pm CET tomorrow.
16:18:43 [richt]
[ negotiating a time to talk about NSD tomorrow ]
16:19:04 [richt]
... we'll start at 1.30pm CET tomorrow
16:19:07 [richt]
s/... so 1pm CET tomorrow.//
16:19:14 [richt]
Cathy: Works for me.
16:19:37 [Cathy]
q-
16:21:42 [jalvinen]
jalvinen has left #dap
16:22:18 [richt]
... we'll start Network Service Discovery discussion at 1pm CET tomorrow
16:22:23 [richt]
s/... we'll start at 1.30pm CET tomorrow//
16:23:27 [richt]
Agenda for tomorrow: http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France
16:25:01 [richt]
Jungkee: Do we have 30 minutes left to talk about Pick Contacts Intent spec?
16:25:08 [richt]
fjh: Probably not time today.
16:25:39 [richt]
Jungkee: Hope to get consensus tomorrow in the meeting. I would like to show a Pick Media demo now.
16:27:01 [richt]
[ Jungkee makes a demo of the Pick Media Intents Addendum API http://www.w3.org/TR/2012/WD-gallery-20120712/ ]
16:34:08 [npdoty]
that confusion is indeed an excellent example of the UI problem discussed earlier
16:35:48 [dom]
hmm... is it? (it does illustrate a potential problem, but not sure that matches the one previously discussed)
16:35:56 [Josh_Soref]
sort of
16:36:10 [Josh_Soref]
in average use, the client and service would have very different visual style and content
16:36:15 [dom]
right
16:36:23 [Josh_Soref]
and the service would show content relating to what it's likely to offer
16:36:31 [dom]
(a potential problem would be a provider trying to blur that distinction)
16:36:36 [Josh_Soref]
whereas the client would have stuff relating to what it was trying to do (and thus that it needed something)
16:37:33 [npdoty]
can the user tell the difference between an Intent that is in progress and creating a new tab via window.open()?
16:37:49 [dom]
ah ok, fair point
16:40:12 [timeless]
npdoty: at this point there is a ui indicator in Chrome
16:40:18 [timeless]
specifically the urlbar has a "change provider" button
16:40:23 [timeless]
beyond that, not really
16:40:32 [timeless]
plus, i'm envisioning intermediate Intents
16:40:38 [timeless]
which are both services and clients
16:40:53 [timeless]
e.g. if i want to pick - video/mpeg
16:41:13 [timeless]
and i have a "make video from slideshow" intent
16:41:42 [timeless]
s/timeless/Josh_Soref/
16:41:44 [timeless]
s/timeless/Josh_Soref/
16:41:45 [timeless]
s/timeless/Josh_Soref/
16:41:46 [timeless]
s/timeless/Josh_Soref/
16:41:47 [timeless]
s/timeless/Josh_Soref/
16:41:48 [timeless]
s/timeless/Josh_Soref/
16:41:49 [timeless]
s/timeless/Josh_Soref/
16:41:54 [richt]
fjh: We'll take a break then we'll have some discussion about privacy.
16:42:13 [richt]
dom: Sounds good but I don't want to get in to the discussion about e.g. specific fields in my address book.
16:42:23 [richt]
... that could get too complicated.
16:43:14 [richt]
s/fjh: We'll take a break then we'll have some discussion about privacy./fjh: We'll have some discussion about privacy tomorrow./
16:43:52 [giuseppe]
giuseppe has left #dap
16:43:53 [Josh_Soref]
s|intent|intent - if that make video from slideshow app is built by using a pick - image/* intent; then i'll click one pick video/*, which loads a tab, and click one pick image/*;multiple which loads a service picker where i choose the gallery which opens in another tab|
16:44:43 [richt]
Jungkee: meta data provided by Pick Contents would be very useful for a lot of services.
16:44:59 [richt]
... Now I'll quickly show the Pick Contacts Intent demo.
16:45:04 [Zakim]
-Cathy_Chan
16:45:40 [richt]
[ Jungkee shows a demo of the Pick Contacts Intent Addendum API http://www.w3.org/TR/contacts-api/ ]
16:48:47 [richt]
Thanks Jungkee
16:49:11 [shan]
rrsagent, draft minutes
16:49:11 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html shan
16:49:32 [richt]
npdoty: We have an informal meet-up tonight with privacy folks for a few drinks for those interested.
16:49:38 [richt]
fjh: Anything else we need to do today?
16:49:41 [npdoty]
privacy get together at 7pm downstairs in the lobby, drinks and maybe dinner too
16:49:51 [npdoty]
everything will be off the record, thx dom
16:50:58 [richt]
[ reviewing today's actions ]
16:52:10 [fjh]
Thanks for scribing Josh, Rich and Bryan!
16:52:20 [shan]
rrsagent, draft minutes
16:52:20 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html shan
16:52:30 [Yoshihiro_]
Yoshihiro_ has left #dap
16:52:35 [richt]
[ meeting closed for the day ]
16:52:52 [fjh]
action: gbillock to work with mounir to create new webintents draft that reflects web activities and issues
16:52:53 [trackbot]
Created ACTION-591 - Work with mounir to create new webintents draft that reflects web activities and issues [on Greg Billock - due 2012-11-08].
16:53:06 [kenji]
kenji has left #dap
16:53:13 [fjh]
action: mounir to Work with Greg to create new webintents draft that reflects web activities and issues
16:56:08 [ares]
ares has left #dap
16:56:46 [timeless]
present+ Harald_Alvestrand, Milan_Patel, GregBillock
16:56:54 [timeless]
present- Geun-Hyung_KIm
16:57:07 [Hidetoshi]
Hidetoshi has left #dap
16:57:10 [timeless]
s/giri:/gmandyam:/g
16:57:21 [timeless]
s/claes:/Claes:/g
16:57:32 [timeless]
s/anssi:/AnssiK:/g
16:57:37 [timeless]
s/anssik:/AnssiK:/g
16:58:11 [timeless]
s/jcdofourd:/jcdufourd:/g
16:58:36 [timeless]
s/jungkee:/Jungkee:/g
16:58:47 [timeless]
s/wonsuk:/Wonsuk:/g
16:59:04 [timeless]
present- Jong_Soo_Oh
16:59:19 [timeless]
RRSAgent, draft minutes
16:59:19 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html timeless
17:02:04 [timeless]
Present- +1.781.266.aaaa
17:03:13 [timeless]
s/aaa:/noriya:/
17:05:02 [smaug]
smaug has joined #dap
17:05:08 [timeless]
s/ddd:/jsoh:/
17:05:32 [timeless]
s/eee:/dnkim:/
17:06:00 [Zakim]
disconnecting the lone participant, Salon_pasteur, in Team_(dap)13:01Z
17:06:02 [Zakim]
Team_(dap)13:01Z has ended
17:06:02 [Zakim]
Attendees were Salon_pasteur, +1.781.266.aaaa, cathy, Cathy_Chan
17:07:21 [timeless]
s/hhh: (missed all that)/daniel_samsung: Soonhong Daniel Park, Samsung/
17:08:27 [timeless]
s/iii: from ETRI/skim: Sung Hei Kim from ETRI/
17:08:59 [timeless]
RRSAgent, draft minutes
17:08:59 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html timeless
17:09:29 [timeless]
present- cathy
17:10:04 [timeless]
present+ Nick_Doty
17:10:42 [timeless]
present+ Hidetoshi_Yokota
17:11:28 [timeless]
present+ Olivier_Thereaux
17:12:01 [timeless]
present+ Youenn_Fablet
17:13:31 [timeless]
s/Geun-Hyung_Kim/Geun-Hyung_Kim_(comus)/
17:13:38 [Shinji]
Shinji has joined #dap
17:14:02 [timeless]
s/yungkee/jungkee/
17:14:28 [timeless]
RRSAgent, draft minutes
17:14:28 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html timeless
17:15:42 [timeless]
s/rss generate minute//
17:15:51 [timeless]
RRSAgent, draft minutes
17:15:51 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html timeless
17:18:13 [timeless]
present+ Soonhong_Daniel_Park
17:18:15 [timeless]
RRSAgent, draft minutes
17:18:15 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html timeless
17:24:18 [sakkuru]
sakkuru has joined #dap
17:26:56 [darobin]
darobin has joined #dap
17:28:12 [fjh]
fjh has joined #dap
17:32:14 [hta]
hta has joined #dap
17:47:39 [smaug]
smaug has joined #dap
17:57:47 [Shinji]
Shinji has joined #dap
17:57:56 [trackbot]
trackbot has joined #dap
17:58:56 [trackbot]
trackbot has joined #dap
17:59:14 [trackbot]
trackbot has joined #dap
19:43:44 [whyun]
whyun has joined #dap
19:50:49 [hta]
hta has joined #dap
20:35:22 [Zakim]
Zakim has left #dap
20:40:24 [tomoyuki]
tomoyuki has joined #dap
21:14:34 [smaug]
smaug has joined #dap
21:17:27 [smaug]
smaug has joined #dap
21:26:43 [whyun]
whyun has left #dap
22:04:23 [kensaku]
kensaku has joined #dap
22:50:22 [giuseppe]
giuseppe has joined #dap
22:51:49 [richt]
richt has joined #dap
22:58:46 [giuseppe]
giuseppe has left #dap
23:23:24 [Alexandre_Morgaut]
Alexandre_Morgaut has joined #dap