<trackbot> Date: 01 November 2012

Administrative

<dom> trackbot, RRSAgent

<trackbot> Sorry, dom, I don't understand ''. Please refer to http://www.w3.org/2005/06/tracker/irc for help.

<dom> trackbot, start meeting

<trackbot> Meeting: Device APIs Working Group F2F

<trackbot> Date: 01 November 2012

<dom> scribenick: bryan

fjh: welcome and logistics
... intros

<fjh> hi I'm chairing, from Nokia, Frederick Hirsch

AnssiK: from nokia, editing a bunch of specs, been out for a while and will catch up

bryan: from AT&T, not editing

jcdufourd: Jean-Claude Dufourd

dom: Dominique Hazael-Massieux, w3

Eduardo: from Telefonica

Jungkee: editing Pick Media etc

Claes: Claes Nilsson from Sony, editing

<jgiraud> jerome giraud: orange

(missing most of them...)

aaa: Toshiba

sato: Sato, Sony

kensaku: Kensaku Komatsu from NTT communications

Yoshiharu_Dewa: Yoshiharu Dewa, Sony also from Sony

<shan> Soonbo Han, LGE

shan: Soonbo Han from LG, interested in Web Intents

ddd: also from LG

jsoh: JongSoo_Oh, LGE

eee: also from LG

Hidetoshi: Hidetoshi Yokota from KDDI

giuseppe: Giuseppe Pascale from Opera

Harald_Alvestrand: Harald Alvestrand, Google, WebRTC chair, observer

hhh: (missed all that)

dnkim: Donyun Kim, LG Electronics

iii: from ETRI

SKim: Sung Hei Kim from ETRI

wook_hyun: also from ETRI

<comus> <geunhyung> geunhyung from Mobile Web Forum

<gmandyam> Giri Mandyam, from Qualcomm Innovation Center

shingak_kang: from (.. Korea)

gmandyam: from QiC, member

<Jungkee> Jungkee Song, Samsung Electronics, working on Pick-*-Intent in the group

<nwidell> nwidell, Niklas Widell, from Ericsson AB

nwidell: Niklas Widell, from Ericsson

youenn: Youenn Fablet, observer, interested in Web Intent and service discovery

<Milan_Patel> Milan Patel, Huawei

(missed the gentlemen before and after Niklas)

(observers)

<mounir> mounir, Mozilla

fjh: agenda

Agenda Review

fjh: goal is to advance the specs, these first are in good shape

<dom> DAP WG home page

fjh: battery spec is in cr, when to goto rec and get testing started is the question
... ambient light and proximity seem stable, the question is whether we can get to last call
... vibration is in cr, need to assess test case status and when we can progress it
... in summary to figure out roadmap for specs in good shape
... may also talk about network info api (maybe shelved)
... also privacy in general, in principle, christine sharing the privacy group may join us
... we kind of pushed the earlier work aside and focused on data minimization, but need to consider revisiting
... we may take longer breaks for discussions
... after break html media capture, in LC and stable but has some comments recently
... we got lc comments, and some responses were not accepted. we need to resolve all today to proceed to LC
... after lunch, web intents all afternoon
... need to review webapps discussion, and discuss status and implementations, issues etc from google
... mounir also is here and we need to take these two pieces of work forward
... tomorrow we will start at nine
... tomorrow on the specs built upon web intents, including calendar to get it moving again
... then claes's work on web intents addendum. cathy is not here (Sandy) but we need to discuss the comments

Claes: there were breakout sessions and will share results

fjh: after lunch richt's network service discovery draft
... somewhere about media capture and streams
... hopefully travis will be here to talk about tracks
... then something about billboards, (digital signage)
... maybe talking about coremob what to do with them
... on interop, a lot of work being done on testing and tools
... been working on the actions and not much to do there
... rough outline so far, anything else?

Minutes approval

fjh: any objection to approving the minutes

proposed RESOLUTION: Minutes from 3 October 2012 are approved.

RESOLUTION: Minutes from 3 October 2012 are approved.

<Josh_Soref> s|Sorry, dom, I don't understand 'trackbot, RRSAgent'. Please refer to http://www.w3.org/2005/06/tracker/irc for help.||

bryan: what about sysapps
... would like to talk about synergy

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Oct/att-0014/minutes-2012-10-03.html

Relationships with SysApps WG

<fjh> bryan: would like to have synergy with DAP, and share common privacy approaches for example

<fjh> bryan: would like to look at privacy more closely

<fjh> dom: how can we be concrete on this

<fjh> bryan: might consider extending existing DAP interfaces in sysapps

<fjh> richt: if it can run in the browser context it should be defined in DAP

<fjh> overlap of dap and sysapps is about five people

<fjh> at least hands raised in the room

jcdufourd: some apis picked up in sysapps have been shelved in this group, it should not be forbidden in another

fjh: we need to be productive, and ensure that browser context use is in the specs that browser vendors will implement
... maybe it would make sense to see how it plays out, but not get into it deep now

jcdufourd: execution and security model is a worse overlap, a meta-level for interfaces

<dom> [43696]=on&ids[58119]=on Overlap of formal participants between DAP and SysApps WG

jcdufourd: how things should work around security

fjh: in other words we should look at it
... there was a contribution in sysapps

jcdufourd: (there are some proposals)

<fjh> ISSUE: should DAP review and take advantage of SysApps security models

<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 .

fjh: concerned about two working groups with different IPR etc not sure what we can do here

nwidell: when the charter was discussed, the sysapps APIs were intended to have a flexible security model

<dom> SysApps WG charter

battery api

AnssiK: ... brief overview of battery status api
... various features exposed for implementation in browsers and web-based os's... works in both world
... sitting in cr for a while. no CRs since then, so the spec is considered stable
... currently a stable version in firefox nightly
... backends are available for windows

<dom> Battery API test suite

AnssiK: been working on a test suite, just run the suite and provide feedback
... it's a bit tricky since automated tests are not possible or easy
... part of the tests address interfaces and others are manual tests
... results are manually validated
... next steps after validation of the suites, moving to PR

richt: we dont have to rush to PR
... what were the implementations so far?

AnssiK: firefox (browser and OS), tizen 2.0

<dom> Implementation status of battery API

richt: has this seen any adoption and interesting use cases?

AnssiK: developers seem excited at conferences
... when you combine this with some other APIs more cool stuff is expected

<AnssiK> * spec in CR since May 2012: http://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html

<AnssiK> * no normative changes since CR, spec changelog: http://dvcs.w3.org/hg/dap/log/tip/battery/Overview.html

fjh: we need to ensure its done right and do not want to rush, but move forward

<AnssiK> * implementation status: Firefox (Nightly), Firefox OS, some WebKit ports (such as EFLWebKit): http://www.w3.org/2009/dap/wiki/ImplementationStatus#Battery_Status_API

richt: the objective is lots of implementations, not just a spec

<AnssiK> * try it on Firefox Nightly (will ship in Firefox 18 unprefixed?): http://nightly.mozilla.org/

<AnssiK> * test suite, reviews appreciated: http://w3c-test.org/dap/battery/tests/submissions/anssik/

<AnssiK> * battery-interface.html is the only fully automated test, others are functional tests

richt: we have hints that clarifications may be needed, maybe leave in CR for a couple or years as we work them out

<AnssiK> * next: move to PR?

<Zakim> dom, you wanted to ask about (other) implementation plans, idlharness and to ask about testing methodology in DAP general

fjh: not sure that is a good idea

<AnssiK> [that was an outline of my talk]

dom: so to recap, just mozilla as a browser today. not sure we should move to PR with just one browser implementing
... any comments from the room?

<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.

mounir: its in firefox 16

AnssiK: will try to provide a live demo

richt: at a design level, its good and on the roadmap with other sensors, competing with other work
... we agree with the approach and the design though

dom: any other implementation plans to share

yungkee: implementation in tizen is complete

fjh: answer is firefox and tizen implementations so far

dom: tizen is not a browser

AnssiK: firefox OS and browser are different too

dom: important to stick to browsers as the goal for implementations

AnssiK: how much platform-specific code is in tizen?

Jungkee: will follow up to see what can be shared

Wonsuk: -> https://developer.blackberry.com/html5/apis/blackberry.system.html#.event:batterystatus "BlackBerry 10" implementation

AnssiK: (shows a demo of tests)
... just looking at the interface as specified, easy stuff
... (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
... calculation is in the web worker, waiting for the discharging time to update... this shows how testing this type of API can be challenging
... maybe webdriver could help, so to emulate some operations
... the test was passed
... after running you have to validate by checking the system battery against what was reported
... 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
... deciding when to prompt the user is tricky

richt: probably should not mark as passed

AnssiK: got the language from the css reftests, to prompt the user on what is expected

richt: in css tests you have visual feedback and also programmatic checking

dom: not sure the harness has this yet, but in this case it's a pass but check result
... someone needs to bring the idea to the public testing list

AnssiK: so the harness API does not support

dom: not sure
... one of the difficulties is testing the API itself and also how it is developed in an implementation

Jungkee: haven't tried this test yet (richt asked)

gmandyam: these are assert tests
... until you have fully charged the battery you can't verify the implementation

<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.

fjh: what I heard is that the test that matters are fully charging and discharging?

gmandyam: time to discharge test requires a full discharge to verify

AnssiK: what you cant do in automated tests is determine if the reported value is the actual value
... you have to check with other data e.g. at the OS level

gmandyam: have compared whats in the OS vs what's in javascript, and found differences... should we consider that in the tests?

<richt> is that difference a rounding error gmandyam, or something more serious?

AnssiK: it's up to the glue layer to define any translations exposed to the browser

gmandyam: can we really say an implementation is compliant, it the reading varies from the OS?

richt: is this a rounding error or a bigger difference?

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

<Zakim> dom, you wanted to mention idlharnes

mounir: we use the exact value that the OS tells you (thru the API), to avoid fingerprinting we take steps

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

<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)

dom: also how much linking test cases with assertions so far?

AnssiK: about 90%
... looking at the spec (highlighting how paragraphs map to tests), its not so easy to separate tests back to prose

dom: and thanks for getting these tests done

<mounir> ack

AnssiK: it's been good to work with mounir, a good collaboration

mounir: to report the issues we have found
... it's hard to test this in hardware, so we are using emulators
... so we change the value in the emulator and verify the change thru the API
... every platform has different implementations, we have found bugs in different OS
... it's not as easy to check any version to see if it's conforming

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
... some divergence is acceptable between the system and user perception
... that this is different from some other estimate that is questionable is not a valid concern

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
... so I can test if the feature is supported thru the API?

mounir: (responds)

<mounir> mounir: the spec defines default values

mounir: we return those default values if we don't have the backend implemented for the platform

AnssiK: if you expose the object but don't have the implementation, we test for that, to avoid fingerprinting via a dummy interface

<fjh> ack

<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

gmandyam: based upon the mobile perspective, we're trying to get developers aware of battery state
... the level is clearly an estimate, but consistency with the OS is important

<AnssiK> … as well as this one: http://w3c-test.org/dap/battery/tests/submissions/anssik/battery-interface.html

gmandyam: I tested the mozilla implementation as input to a paper for the web performance workshop next week
... when I discharged the battery all the way, there was a clear discrepancy in the javascript (20-30%)

<AnssiK> [the first test is useful *only* if there's no backend impl]

Josh_Soref: that's the type of bug we need to see reported (it's ok, for the UA battery report to indicate dying sooner, but not ok to report dying after the OS)

<mounir> gmandyam: on which platform?

fjh: so next steps with this work

AnssiK: will continue on the tests, will test tizen devices when available (also firefox OS, please provide one!)
... about the next process step

richt: before we have finished specs, and shelved with no implementations. we should expect some inertia now, and some time before wider implementations
... its not a huge concern to get to PR, but we cant progress at this point though the spec is still alive

AnssiK: IP committments kick in in REC so we need to get there asap

dom: until we get another browser implementation the question is pretty moot

<fjh> ACTION: dom to review Battery test and contribute more tests [recorded in http://www.w3.org/2012/11/01-dap-minutes.html#action01]

<trackbot> Created ACTION-585 - Review Battery test and contribute more tests [on Dominique Hazaël-Massieux - due 2012-11-08].

AnssiK: would be better if someone else also contributes tests

richt: lack of implementation does not imply disagreement (want to make that key point)

dom: we have made a call for implementations, otherwise the spec is ready

richt: there doesn't seem to be disagreement, just not clear and broad agreement

dom: one open question, what is the process for approving test suites
... by default, by review, etc
... the default is that they are approved until problems are found

richt: think we should have a code review
... W3C should have such systems in place

<fjh> ACTION: richt to review Battery tests [recorded in http://www.w3.org/2012/11/01-dap-minutes.html#action02]

<trackbot> Created ACTION-586 - Review Battery tests [on Richard Tibbett - due 2012-11-08].

Vibration API

AnssiK: spec is in CR since may
... minor clarifications, implemented in firefox OS, tizen. test suite draft by robin

mounir: also firefox android

<AnssiK> * spec in CR since May 2012: http://dev.w3.org/2009/dap/vibration/

<AnssiK> * minor clarifications since CR, changelog: http://dev.w3.org/cvsweb/2009/dap/vibration/Overview.html

AnssiK: its exposed to the browser but if it doesn't have the hardware it won't do anything

<AnssiK> * implementation status: Firefox, Firefox for Android, Firefox OS, WebKit: http://www.w3.org/2009/dap/wiki/ImplementationStatus#Vibration_API

<AnssiK> * test suite draft by darobin: http://w3c-test.org/dap/tests/vibration/submissions/robin/

<AnssiK> * test suite TODOs: http://w3c-test.org/dap/tests/vibration/submissions/robin/TODO.txt

<AnssiK> * next: work on the test suite

Wonsuk: clarifying, wekbit supports many browsers based upon linux (a lot of ports)
... the EFL port has many browsers in testing. this may be helpful to CR?
... (this was related to the battery API, not Vibration)
... Tizen is a Web-based OS, but provides different context (system app and browser)
... we can provide test results based upon tizen for our target devices. will that be helpful to move to CR for the battery API?

fjh: will the open-source status of the browser should help (this is the question)

dom: is it a shipping browser that has battery, or an experiment

Wonsuk: it's testable in a test environment based upon the EFL port

dom: what we want is real browsers that are shipping to leave CR

richt: 2 is the minimum

<fjh> bryan: does browser implementation mean installable on any platform?

<fjh> timeless: apis for general web apps for general browsers in general deployments

<fjh> timeless: test implementation not suitable for exiting CR

timeless: the browser needs to be a major browser, not puppet implementations

<fjh> need to clarify in battery API status that exit criterial for CR is 2 independent real world browsers

dom: technically we need to have two implementations, two real-world implementations independently sourced

<fjh> ISSUE: status section of Battery CR draft should include exit criteria and at-risk items

<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 .

bryan: we are expecting real world implementations expected for wide use, not just the "big five"

<GregBillock> re: battery implementation in webkit, see https://trac.webkit.org/browser/trunk/Source/WebCore/Modules/battery

<GregBillock> (I don't see it is enabled by any webkit-based browser currently.)

dom: we need an exit criteria (not necessarily well-defined), and the director will make a decision whether we have really met the criteria

HTML Media Capture

fjh: we have a LCWD with some feedback

<fjh> general comment on HTML Media Capture comment http://lists.w3.org/Archives/Public/public-device-apis/2012Oct/0050.html

shepazu is here

fjh: thought about comments of doug
... e.g. might want mic vs video, different use cases
... other comments about front vs back and selection
... other work in media capture, with streams and tracks etc... this seems related to the goals
... maybe that's the solution, and it shouldn't be in html media capture

bryan: +1 to reuse

fjh: mime types dont seem to relate to the track objectives etc... what problems are we trying to solve?

shepazu: comments are more about setting correct usability and privacy expectations
... e.g. get camcorder. does that necessarily include audio, is video recording automatically include audio?

AnssiK: think that users will expect what the native platform would provde
... that is an implementation concern

dom: to be clear, the html media capture is a shortcut to enable recording
... giving direct access to the native application through a button for example
... the user doesn't have to 1st record and then upload. but it still uses the basic OS framework, and nothing extra
... the media camera API will provide that

fjh: we need an intro section setting expectations

shepazu: the rewrite should address the relationship with getusermedia

fjh: agree we have a spec that is unclear per the landscape

shepazu: need to clarify that "camcorder" includes audio. that needs to be clear.

dom: again camcorder only starts the native application

shepazu: in that case the author needs to know if they will get audio

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
... clarify as Dom mentioned that is shortcut for file upload

dom: the application just hands the user to the native feature

<shepazu> http://www.w3.org/2012/09/26-audio-minutes.html#item05

dom: normal operations result and when coming back to the app, the user will find the file and then upload etc

shepazu: upload what, does it include audio?

dom: if you need more control from the app, you need to use getusermedia

<shepazu> Audio WG concerns with HTML Media Capture API -> http://www.w3.org/2012/09/26-audio-minutes.html#item05

olivier: there are different perspectives on what features are involved here, but it doesn't sound future proof

<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 Audio WG concerns with HTML Media Capture API|

olivier: we are talking about images, audio, and video, not just what devices give you those
... from the audio WG we are worried that there are two APIs providing the same things

AnssiK: we do need to clarify the keywords
... e.g. capture is "still image capture device"
... and camcorder is a "motion capture device"

shepazu: is this the wording or the keywords that are proposed to be changed?
... motion capture can be haptic etc, would suggest to use "video"

fjh: how real an issue is "camcorder" vs video?

olivier: the concern is more about consistency

shepazu: camcorder is an old term

Josh_Soref: (proposes an experiment)

<Josh_Soref> s/experiment -- and it fails -- miserably/

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
... more generally, we have a "accept" attribute that enables selection of the type of file to get
... what ends up is a launch with filtering of the selected tools
... it's fine the way it is

shepazu: agree that there is a place for this, it addresses use cases getusermedia does not
... we need more explanation of how HTML is being extended, and that expectations for the author and user are not being clarified
... don't want the author to guess what the app will offer to the user

fjh: we got a comment that we need more clear text

AnssiK: we do need to more clearly describe how the options address the different use cases

shepazu: that would help, for that part of it

fjh: so there is not enough info for a first time reader to understand, and we need to improve that

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

fjh: we need to say something related to the content in the file (audio vs video)

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
... you get just the ability to select a file type

shepazu: it's not just the file. you are interacting with the application, e.g. a video camera, not a file type

dom: we are not getting a camera, but the file object
... what does is saying is that informative language update may not be enough

<Josh_Soref> file picker with scanner

dom: once you have the file, the app may be able guide the user to do something different as needed by the app

<Zakim> Josh_Soref, you wanted to say that the option thing is silly since, ideally the UA will just do this automatically

dom: if the app needs more control, then it needs to use getusermedia

Josh_Soref: dropped in picture links

<Josh_Soref> file picker with cameraq

Josh_Soref: want to note that people used to think of windows explorer as a file picker
... this is now false, the picker can show other things as virtual files e.g. a scanner
... the picker can offering ways to get data of a source, that could include hints to the user
... the user can select different sources of the same type, e.g. an image or a camera
... but in the end it's just a file that is being selected. if more is needed the app should use getusermedia

<Josh_Soref> s/cameraq/camera/

gmandyam: a broader perspective, prior to joining the DAP WG, ...
... I heard two arguments in favor of html media capture
... the first is a bogus argument, don't see the value in adding a new DOM element just for capture
... also the argument over the privacy approach is bogus
... even though getusermedia is still being developed, we can expect that a dialog box will provide the user with options also
... in the next few months we will have similar and better capabilities with getusermedia

dom: responding, was at the mediacapture TF meeting, and its optimistic that in 6 mos we will have a stable spec

<Josh_Soref> Josh_Soref: +1 (i minuted)

dom: 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
... a simple declarative way to get a picture without dependency upon detailed features

<fjh> +1 to having simple interface for functionality in addition to getusermedia that offers more control

dom: coremob also has identified the use cases of getting a picture as important

gmandyam: expect javascript libraries to extract away the complexity for those apps that need just a simple picture capture

dom: agree libraries can also get the same output, but the library can't expose things equivalent to the default UI of the device

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
... this is not about control over the file, just selection
... making it easier for the users to get to the file (type) they want to share

<fjh> "a quicker picker"

richt: purely innovation at the file picker level

AnssiK: love getusermedia, great for its use cases
... 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
... additional point for doug, about privacy/security. if an app wants audio + video, but I don't want audio just the video, ...
... i need the freedom to get the video without the audio

shepazu: you should be able to express what you want, and the user should be able to modify that
... saying accept to one file type, doesn't necessarily imply both types of content are acceptable
... want the user to know what the app's expectation is, and to give the user the option to choose

dom: html can be used to express to the user what the app expects, before they click the button

<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/

richt: understand the intent, that user opt-in to audio is important
... that's not a feature of the native application, to offer that control by an API of the platform

shepazu: when you popup the dialog, you chrome can't popup something that clarifies what is asked for?

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

shepazu: you can ask it, whether it listens is another matter

olivier: at the moment you can, but specifying it is a start and will promote development of the native APIs

<Zakim> shepazu, you wanted to support the use cases for this spec

shepazu: those who are developing platforms are in control, and can develop this. we just need to make it possible thru the spec
... the audio WG wants the html media capture spec, to get to market quickly.
... getusermedia will take longer, and in the meantime this is critically important
... really support the spec, but want it to be done right

dom: the only thing not possible is to enable recording of video only?
... to separate the video and audio?
... what is the use case, when would you want that?

shepazu: if you want videos, but have privacy concern about the collection of an audio track

richt: we could put that in the dialog, and hand off to the native app, then strip the audio out

<npdoty> there are some legal jurisdictions where recording audio requires a higher legal bar than capturing video, fwiw

shepazu: not asking for that, just to inform the user

fjh: would it help to have keywords to allow the separate source types to be included

shepazu: more keywords seems more complex... my solution is to have a list of what is requested

fjh: so what olivier is requesting is that we think ahead

<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./

<Josh_Soref> BlackBerry File Picker with Camera

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?

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

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

richt: getusermedia is about staying in the browser and getting the media
... this otoh is about switching to the native app seamlessly
... they are different use cases and both needed. there is no choice between these, they are both important

<Wonsuk> +1 for richt

fjh: suggest we get to the LC concerns and address them well

<AnssiK> LC comments: https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/doc/

fjh: it would be useful to look at the LC comments each to see if something has been missed, or is it this one issue?

Josh_Soref: doug wants to specify what is requested
... (showing the blackberry UI)
... we can already map the accept list to this type of dialog

fjh: can you do the camcorder case without audio?

Josh_Soref: probably not today
... 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

shepazu: i understand where you are coming from, maybe rewrites can make it clearer

olivier: a lot of the discomfort came from the spec being unclear. from today, i recommend renaming it to "media file" capture

richt: a demo may help clear this up

<richt> richt: Josh_Soref has a demo that people should look at during the break.

fjh: we have some more time, and have covered doug's concerns (though not solved them)
... you believe that we should provide the ability to ask for more granularity

shepazu: yes, from a privacy perspective there is additional work needed
... also it would be useful to share discussion with the audio WG
... some overlapping members can help us discuss this

fjh: we should go thru the other comments now

Josh_Soref: (showing a demo)
... facebook, with a photo button
... on click the button, files are offered but don't want them. another option is the selection of a new picture
... the same behavior applies to other recording cases

fjh: going to other LC comments
... 2641 was about front/back

AnssiK: this relates to the same discussion about audio/video... you should use getusermedia instead
... 2637 is one we have to decide on, but not now
... 2640, about html will be easy to resolve
... 2638, asking for an example, we can say this is solved and do it with the other comments of doug
... 2639, re camcorder as name, this seems not an issue anymore... any objectors in the room? if not, propose that we close this one

<gmandyam> q

AnssiK: lack of speaking up means consent

nwidell: what is the relationship of the use of camcorder for getusermedia?

<Josh_Soref> GetUserMedia

<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.

fjh: they talk about tracks and streams, so they don't need to go there
... 2642 is done, not sure there was a response yet. we dont need to do anything more until a response
... 2644, is addressed and done, and response is OK so this is closed

<AnssiK> LC-2644 +1'd by commentor at: http://www.w3.org/mid/001401cd96e5$7a73f7b0$6f5be710$@murthy@cmcltd.com

fjh: two things needed to do, informative changes (any contributors welcome)

<nwidell> (intent of my question was just if there was a need to align attribute names e.g. "camcorder" with somthing equivalent in getUserMedia

fjh: also to rename it to "HTML Media File Capture"

bryan: is this just to be clear that a discrete file is delivered vs a stream?

<AnssiK> "HTML Media Capture" v "Media Capture and Streams"

fjh: 3rd things is to resolve the audio/video selection

<fjh> s/rename it to "HTML Media File Capture/ rename it for clarity, possibly HTML Media File capture/

bryan: they should be fine with the name, HTML makes it clear this is declarative

<fjh> s/rename/consider renaming/

AnssiK: also don't think we need to rename, they should be fine with this

fjh: so we are done with this?
... would like to do more on vibration and wrap that up
... we were talking about how it couldn't be generic as not all platforms have this feature, and testing

<AnssiK> http://w3c-test.org/dap/tests/vibration/submissions/robin/TODO.txt

AnssiK: we have a todo list
... i volunteered to write the tests, welcome any support. also need some hardware to test it on.

mounir: believe its in firefox OS

AnssiK: is there a way to emulate it somehow?
... will take it offline, and talk with tizen for testing

Jungkee: samsung colleagues implemented this for webkit

fjh: so we need hardware and tests for vibration to proceed?

AnssiK: writing test cases is boring without hardware to test against

fjh: going on to proximity and ambient light sensors

<spoussa> me can give AnssiK Tizen reference device for battery and vibra testing.

gmandyam: the call for exclusions for ambient light just came out

AnssiK: we have one implementation for proximity events, and it shares the design for ambient light
... at least for proximity, we could move to LC. marcos did the tests for it

gmandyam: Ian sent an email today for exclusion

fjh: need to know if the WG thinks the specs are stable and can move to LC

<AnssiK> * spec WD in Jul 2012: http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html

<AnssiK> * test suite: http://w3c-test.org/dap/proximity/tests/submissions/marcos/

fjh: who is involved with ambient light?
... can do a CFC

<Josh_Soref> s/CFC/CfC/

proposed RESOLUTION: publish a LCWD of the Proximity Events spec

RESOLUTION: publish a LCWD of the Proximity Events spec

fjh: it will be after the F2F when pubrules has been checked etc

<fjh> ACTION: anssi to prepare Proximity LC draft and run through pubrules [recorded in http://www.w3.org/2012/11/01-dap-minutes.html#action03]

<trackbot> Created ACTION-587 - Prepare Proximity LC draft and run through pubrules [on Anssi Kostiainen - due 2012-11-08].

<fjh> ACTION: fjh to review exclusion period for Ambient light [recorded in http://www.w3.org/2012/11/01-dap-minutes.html#action04]

<trackbot> Created ACTION-588 - Review exclusion period for Ambient light [on Frederick Hirsch - due 2012-11-08].

fjh: re Ambient Light Events, we should be ready for last call

<fjh> ACTION: fjh to send CfC for Last Call of Ambient Light Events [recorded in http://www.w3.org/2012/11/01-dap-minutes.html#action05]

<trackbot> Created ACTION-589 - Send CfC for Last Call of Ambient Light Events [on Frederick Hirsch - due 2012-11-08].

<Josh_Soref> i/vibration and wrap/Topic: Vibration/

<Josh_Soref> i/proximity and ambient light sensors/Topic: proximity and ambient light sensors/

Network Information API

fjh: Network Information API was not shelved

break for lunch

returning at 1:45 PM

<timeless> scribe: timeless

Network Information

<adrianba> ACTION-474?

<trackbot> ACTION-474 -- Adrian Bateman to make a proposal for Network Information API -- due 2012-10-15 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/474

<Josh_Soref> adrianba: i've had an outstanding action for a really long time

<Josh_Soref> dom: one year

<Josh_Soref> adrianba: bad news, i may not be closing it today

<Josh_Soref> ... but i'm making progress

<Josh_Soref> ... this is about making a proposal for a network information api

<Josh_Soref> ... there was some disagreement

<fjh> http://www.w3.org/TR/2011/WD-netinfo-api-20110607/

scribe: one about reason for using it
... then there was a concern about bandwidth
... and whether the right network would be selected
... there were concerns about bandwidth determination and power use to determine it
... W8 includes network info for applications
... what i want to talk about today is giving you an update of what we're thinking
... what we've heard from app developers
... it may be inconclusive
... the main reason for this seems to be "Bill Shock"
... customer being billed for
... amount of data being used
... what we'd like is for applications
... to respect the kind of network
... and change their behavior
... this can be dealt w/ at two layers in the app stack
... one is for the system to make appropriate changes based on the network
... for the UA to make changes based on the network characteristics
... network perf of your site-web app
... will be better because UA did intelligent things
... app dev doesn't need to change any of their things
... to get benefit
... choosing to not precache video
... from a <video> element until someone presses Play
... in an adaptive stream media content
... it might be imposing a maximum on bandwidth for streaming
... in html
... we were talking about Responsive Images
... the browser might choose to download the smallest possible image for a page
... if that might use less data
... this is us saying "we should try to design features into the open web platform that can be intelligent"
... so when we're designing features
... let's be thoughtful about how the UA could change behavior for a Metered network
... second is about APIs in this space
... for web application to do something intelligent
... it knows what it's trying to acheive
... we've had feedback
... we just want to provide the best experience to customers
... we don't want to degrade the experience to customers
... we don't really know
... for certain key, high volume, high value web applications
... they definitely want to
... applications they leave open for a long time
... social networks, web email clients
... developers of those apps want to do something
... am i supposed to be conserving bandwidth, or not
... that's the primary thing they care about
... for w8
... a place where we've got the experience / information available
... we didn't include anything in the app requirements to be aware of metered networks
... it's purely up to them
... we have very few apps taking advantage of this right now
... there are 25
... written within MS that do use this
... considered to be an important part of the app
... related to the same scenarios as web sites
... long running applications that constantly talk to the network
... we have several MS owned web properties keen to take advantage of this as well
... Outlook Web Access / Latest release of Exchange
... it supports mail offline in IndexedDB
... downloads messages or maybe only headers
... commonly part of installed thick client applications
... high value applications
... makes it different to figure out how to prioritize
... if it's only in IE, it's problematic
... from our research, i don't think we should write it off as a problem that doesn't exist
... that people don't want to solve
... but perhaps it isn't the highest priority thing to work on in the group
... as deployment incresaes

s/incresaes/increases/

scribe: there will probably be more demand
... and we can look at this more highly
... interested to hear if people have heard the same/different things

fjh: i don't think Shelving is the right word
... shelving is "we want to do something different, but low priority"

adrianba: i think some of the concepts in the current proposals ARE WRONG
... i don't think trying to determine available bandwidth is useful
... trying to know if it's metered is useful

<richt> Opera on the Network Information API > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036116.html

richt: i agree with a lot of what adrianba is saying
... comments from jgraham
... we have issues getting bandwidth numbers
... but what's at issue here is if it costs
... there's forking if you get Bandwidth info
... Mobile v Real web again
... uses are Streaming the right video
... it's not fork the resources based on bandwidth
... there's some UCs here we want to solve
... but this approach is not optimal
... the implementations aren't great
... they're sort of hard coded, we could change it to get it right
... but we haven't got what it takes now
... I don't think Opera plans to implement this anytime soon
... we don't have to get bandwidth
... right now we're reporting back to the developer
... maybe we can report to the UA what it wants/needs
... that'd be more privacy preserving

<Zakim> bryan, you wanted to ask how does the UA know the network is metered?

bryan: if bandwidth calculation isn't worth the effort
... and primary UC is "is metered?"
... how does the device know the connection is metered?

<richt> s/it's not fork the resources based on bandwidth/it's not fork the user experience based on bandwidth/

adrianba: we in windows, we have Network Configuration that understands the network we're connecting to
... the network is registered as a metered network

bryan: how?

adrianba: if i'm exporting a connection to a 4G network
... that connection has associated billing characteristics

bryan: how?
... through what specification

adrianba: this is a windows feature

bryan: this doesn't seem like an interoperable thing today

adrianba: how that gets configured to the device is out of scope
... i don't believe it's in scope for this WG
... happy to have that conversation about standardization, but not here

bryan: just is that a valid argument for shelving

adrianba: why can't every UA have a config option to say if it's metered?

bryan: users don't know ?
... number of reasons
... primary driver is to save money
... i'd say from our perspective, as a service provider
... facilitating more effective use of network resources
... probably a more important use of an api
... we'd like to take advantage of WiFi
... without knowing that
... we don't have any way for apps to make a decision
... how could an app indicate to a UA the type of network they'd prefer for a particular network to be retrieved?
... leaving all decisions to UA/connection manager is problematic
... seems to be a gap in understanding true needs of an application
... content for particular resource
... and what would benefit a UA
... metering isn't the only UC

<Zakim> Josh_Soref, you wanted to point to Web Perf/Nav Timing/work on http timing

<fjh> Josh_Soref: to deal with bandwidth or source of information can look to web performance wg to deal with this

<fjh> Josh_Soref: network performance will not just depend on network, could depend on server, country it is etc

<fjh> Josh_Soref: not every network is metered

<fjh> Josh_Soref: agree with what adrian has said

<fjh> Josh_Soref: user agents improve since ???

<seo> rss generate minute

<fjh> s/???/as they can get this information/

<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

<fjh> Josh_Soref: can tell if on wifi or cellular by using DNS

<fjh> dom: who do you know by DNS

<fjh> Josh_Soref: DNS record for phone will say network

<fjh> Josh_Soref: reverse DNS lookup gives different host domain

<fjh> dom: worldwide?

<fjh> Josh_Soref: improvements needed

<bryan> is the DNS approach a standard or enforced?

<fjh> s/needed/needed to some network providers

<fjh> s/needed/needed to some network providers/

<bryan> so the UA needs to use the DNS protocol to know?

<Zakim> mounir, you wanted to ask if keywords would be more interesting?

Josh_Soref: no, the server side can do the DNS lookup

<bryan> how does the UA know that the app wants a specific content delivered via WiFi?

mounir: about type
... i don't think we should show that for privacy reasons
... it adds bits of finger printing
... it helps tracking people
... you can try to guess where they are
... i don't think there's a real UC for knowing the type
... most of the time
... "we want wifi" because "we want fast network"
... they don't really care if it's wifi or 4g or cable
... they want fast

<bryan> re type, josh just said that this is easily discoverable via DNS, so avoiding providing this information locally provides no additional privacy value

mounir: about metered, as Josh_Soref said
... it's hard to do right now
... but it's easy to improve
... if we have a Spec for that
... it's easy to improve later
... as MS is doing to push carriers
... and about bandwidth
... we may still have UC for that
... i think some apps might want to save bandwidth if you have low battery
... regarding UX it might be better
... i wonder if checking battery to something accurate
... to KB
... to track if you're slow or fast
... might solve some issues
... and keep the feature

<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

dom: what's the UC for bandwidth?
... adrianba said research showed
... no real use for this
... do you have concrete UC
... or know of real apps that would use it?

mounir: i don't have an example of an extension using that
... we could make up one

<bryan> getting dynamic metering info (where you are in the billing cycle, or how specific resource would affect your plan) is even more difficult

mounir: but for Battery API, there's a argument of no UC for it
... but if i don't have such a feature, then.. how can you use it?
... it seems like a chicken-egg problem
... i'd appreciate if my email client doesn't fetch body on low bandwidth

dom: does firefox os have this?

mounir: no

sicking: when we started this work
... we spoke to PhoneGap
... and asked what apis people asked about

<bryan> josh that is not correct, small packet transmission has a much different power profile

sicking: they said a big request was for Edge/WiFi/3G
... they had a bunch of apps that wanted to know
... if they had a high bandwidth video and a bad connection, they knew it was going to fail

<AnssiK> PhoneGap's Connection API: http://docs.phonegap.com/en/edge/cordova_connection_connection.md.html#Connection

sicking: their UC was to avoid initiating a network connection if it was going to fail
... if you want to avoid doing connection, you've already lost

<AnssiK> [PhoneGap aka Apache Cordova]

sicking: no particularly strong UCs for WiFi v. Ethernet
... not even 3G v. WiFi

s/../.../

scribe: but Edge v. Other stuff
... same thing w/ online v. offline
... you can argue it's useless
... we still have it

Josh_Soref: because you can't get rid of it

dom: just relating what adrianba said

mounir: adding Type
... some people seem to want it back
... before my proposal
... there were property name for connection
... "If 2G or 3G, we're slow"
... i doubt 3G is "always slow"
... wifi can be way more slow than 3G
... which helps for UC
... adding slow connection
... a better UC for bandwidth is Games
... if you're playing games
... you may want low bandwidth

gmandyam: talking w/ a Qualcomm hat on
... we do know there are many situations
... just because you have WiFi, doesn't mean you're getting an increased throughput
... while you're staying in the same location
... developers making a decision based on that
... are not always going to make the right decision

Josh_Soref: +1

gmandyam: even though bandwidth estimation isn't passed
... at least on a handheld device
... if it isn't matching the modem estimate
... it isn't good

<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?

gmandyam: it's a MUST that browser vendors do this with the chipset vendors
... if they're not able to do it, it isn't a worthwhile feature
... OMA is actually looking into similar activity
... they just standardized a Connection Manager API
... they're talking about a JS API
... a readonly API
... we doing it, they doing it, will cause confusion
... like to see that resolved

fjh: [ adrianba left ]
... need to make time for web activities/intents
... do we shelve/discuss?
... after bryan + Josh_Soref, maybe straw poll?

bryan: key points
... we shouldn't let the perfect be the enemy of the goood

s/goood/good/

scribe: this is definitely a valuable feature

<dom> [my sense is that there is rough consensus that "metered" is a useful feature; bandwidth/type is more controversial at this time]

scribe: network operators want apps to be smarter
... they want apps to have a consistent experience
... if not addressed in W3C, it'll be addressed somewhere
... i'd prefer the open web to develop it
... connectional information is important
... rather than telling the App what it can know
... if the app could tell the platform "this is what i would like"
... "deliver this over WiFi"
... dropping everything because some things could be done

<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

<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]

<fjh> Josh_Soref: if you receive multiple packets at one time versus individually power usage will be less

<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

<fjh> s/be less/be less, if the radio only turns on once/

<fjh> Josh_Soref: deliver over unmetered can be in source set (?) specification

<fjh> Josh_Soref: agreeing with adrian here

<fjh> s/source/src/

<dom> (@srcset is a very specific and limited use case for metered)

richt: progressive enhancement
... by giving web page, we're assuming web pages to know what to do with it
... by giving web page the information
... we're letting the pages create a 2 tiered scenario

<fjh> s/src set/srcset/

richt: we want to be able to let metered UC handle
... it doesn't have to be in JS
... it could be in HTTP headers
... it could be a button in UA

<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

richt: "turtle" throttle from this point onwards
... there's lots of different ways
... i don't think we're at a solution

nwidell: after this, i think we need a better understanding of UCs
... there's Bill Shock
... bandwidth Adaptation
... which can be done server/client side

<fjh> potential action on proponents of use of network information API to document APIs

nwidell: i don't think we should shelve it right away, get UCs first

fjh: i don't think we should shelve it right away
... i think we should get UCs documented
... i think on the home page we could put a notes saying this group is still reviewing spec

mounir: we should make clear there's two specifications
... people get confused

AnssiK: /tr doc is out of date

dom: we should update /tr

mounir: i can do that

dom: updated working draft saying we're exploring the space
... bandwidth has Issue
... metered seems interesting
... putting UC in this
... i'm happy to put note

mounir: i can add UC section to spec

jcdufourd: please

fjh: published TR is out of date
... best way to publish updated WD
... create updated WD, publish, update SoD
... make clear it's under discussion
... updating UCs
... i'll give an action to do that to mounir
... dom can help
... and we agree to publish updated WD
... any objection to publish updated WD

<richt> The use cases are important but we might be able to find a better solution.

<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.

RESOLUTION: Publish updated WD of network information

fjh: nothing else required for publication?

dom: people may want to see draft before

<fjh> ACTION: mounir to prepare updated WD of network information with updated status, including addition of use cases [recorded in http://www.w3.org/2012/11/01-dap-minutes.html#action06]

<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].

<fjh> we will share draft in group for review before publication

dom: nwidell are you offering to help w/ UCs?

<fjh> nwidell: yes will help with use cases

dom: don't be blinded by solution, focus on documenting problems

fjh: mounir, when can you update the draft?

mounir: within a month?

Web Intents/Web Activities

fjh: unfortunately, my plane was delayed by #Sandy
... GregBillock, i'd like to go through the issues
... understand web activities
... understand fundamental differences
... figure out what group wants to do?
... go from there?

GregBillock: current Chrome impl... i could show again
... it takes time
... current state, it's behind a flag in Chrome 24
... you go to chrome://flags and enable
... web intents from there
... implementation, mostly UI issues
... they're significant enough
... they're potentially needing api issues
... there are different dispositions for Web Intents services
... one is to render inline on top of the existing invoking tab
... kind of the experience -- tab modal dialog showing service
... backed by browser, overlaps location bar a bit
... you can tell it's a different surface than the original tab service
... you're still in the same task context as it were
... nice because it's related to what you were doing
... but it's a bit more difficult to adapt existing web apps to conform to that
... we decided to have a window disposition
... basically multiple tabs working on the same intent
... difficulty is letting user know this is what's going on
... couple of edge cases
... imagine editing a document from one tab
... if you close that
... and editor doesn't have a way to persist your changes, you can lose them
... we have a general concern
... if user isn't comfortable using tabbed browsing
... they might not understand this two tab thing
... the other one i talked about yesterday
... is the issue...
... initially we imagined the Service Picker
... we didn't want to expose what the situation was w/ installed services
... we wanted to leave open for the browser to let the user discover new services in the picker dialog
... that's worked out a lot less well than we thought they would
... users are a lot less comfortable with extensions
... don't understand what's offered
... the workflow w/ 4 steps deep install + authenticating
... it interrupts flow= bad experience
... that's a more significant challenge to the way we envisioned the feature working
... we may be after a way closer to the way hixie proposed on WhatWG
... closer to RPC/RPH
... semantically, users choose an application to fulfill service
... bypasses the need for showing service selection dialog
... that service selection process would have fewer problems
... not saying we should do that
... but...
... the UI problems we came up w/ have an impact on how we view semantics / how we shape the api
... not sure that's the solution
... it's not just something the Chrome UI people will sit down and solve
... but it affects the API level as well
... those are the main points
... a couple of things we've discussed in Intents list
... are making things closer to hixie's proposal
... and web activities
... changing window.intents delivery
... we assumed we'd always do intent delivery to a brand new context
... based on feedback from people who wanted to use the feature w/ an open application
... even if we kept the existing spec
... we'd want to make changes like that
... using a message to do delivery instead of window.intent
... and another thing is mirroring the RPC api for intents

gmandyam: i'm confused as to what you found in chrome
... how that impacts the normative text in the spec
... normative text doesn't get into UX
... also
... i haven't personally tested out explicit intents
... shouldn't that really be the fallback?

GregBillock: nothing in the normative text in the draft text reads on the UI in the browser chrome
... the way they feed back
... users should be using web intents because they're easy to use, easy to discover
... but they find the selector dialog confusing
... intimidating
... since that happened, we're considering perhaps not the same api
... if we change how we imagine connecting services
... we might have a different api that does that job
... it's possible we'd have a more navigation based solution
... if we have a mechanism that treats primitives of app construction
... the way they can be addressed in construction
... take an example
... i have an offline enabled app that supports a photo sharing site
... there's a button in it "please share this photo"
... you get a page in that app that does sharing to that service
... but the way you get to that is through a navigation transition
... it could be a different api

gmandyam: seems like it's part of a broader problem
... part of it is a discomfort with web stores in general
... which is part of why i think it's a mistake to consider modifying the proposal

GregBillock: there are some who'd rather things closer to bookmarks than a web store
... perhaps goes to sysapps
... think of what the right solution is

gmandyam: while we wait for better user acceptance of web stores
... we should make sure explicit intents is properly implemented

GregBillock: explicit intents
... is an important ingredient
... it wasn't there at first
... it was one of the things that jumped out of this
... a lot of people saw intents as important for transitions within their own applications (beyond just cross app)
... i agree that's important
... direct invocation
... -- web apps that are composed of elements that can be linked to
... my best guess is that a navigational metaphor is the best way to think of
... just an intuition

AnssiK: have you prototyped window-disposition in small phones?
... in small screens, it just doesn't work
... it kind of works on big screen
... but for mobile, it seems awkward

GregBillock: good question
... we hadn't done any on small screens
... our idea for how that'd look
... if you look at Chrome on Android and how tabs are there
... you'd transition
... they'd be "tabs", but presented in a full screen
... just as all "tabs" are in Chrome for Android
... in some ways that's an easier UI to solve the problem
... in terms of confusing UI
... on a small screen, you don't have the same opportunity for confusion
... about what not to touch
... a small screen ends up being modal
... for users who don't care about mechanics about who's operating screen when
... it's always overlapped/inline
... those problems are "easier" to solve
... if anything, small screens were easier
... the tricky worries come up w/ multiple tabs on larger screens

AnssiK: what's your message to developers relying on the current web intents api?
... developers get mad

GregBillock: we're going to post a message on WebIntents G+ group and discussion forum
... letting people know we're putting it behind a flag
... the implementation is limited to apps in the store
... so we have a fixed list of services to speak to
... not a lot of web content relying on the existing impl
... we experimented with Chrome
... and were finding workarounds internally
... not sure about reaction of putting behind a flag
... it was vendor prefixed
... that's not something vendors understand

AnssiK: i wouldn't be surprised if it made headlines in HTML5Weekly

<Zakim> fjh, you wanted to ask about privacy and user interaction

fjh: GregBillock, you said Usability testing
... showed they couldn't handle the selection
... but i thought that was what we used for privacy control

GregBillock: UI problems
... relying on UI to guide normative parts
... the thing we were talking about w/ Store model
... people decide to adopt a particular app
... probably because they know the vendor/institution
... and they invest agency in that app
... that bundles trust transactions
... once they decide to use an app
... they accept the permission bundle
... there are people eager to do that because it makes their browser experience better
... some don't understand what it means
... people can opt out
... We saw use of Selection for Discovery wasn't working as well as we expected
... it's long, involves authentication
... you lose track of where you were?

s/?//

scribe: trying to use that capability to get this job done

<Zakim> bryan, you wanted to ask what info suggests users are uncomfortable with web stores

bryan: gmandyam mentioned users not adopting web stores
... what indication is there to users not adopting them?

gmandyam: i was asking that
... it seems like GregBillock confirmed that
... classic users with some confusion
... i agree w/ bryan, there's no Google Play version for Android today
... a large segment of users who can't use it

bryan: i see some people have developed a way to load extensions in their syste

s/syste/system/

scribe: i don't see activity to build market
... it makes sense to simplify UX
... i'm wondering how the shift from the UI experience
... would affect discoverability

ack

s/ack claes//

s/ack//

Claes: having 2 tabs, one for client, one for service
... what about just having the service application in the same tab as the client, just replacing the client application
... which means he can't close the client app
... other was about the picker
... as i see it, it isn't just about picking, but also trust

GregBillock: one possibility is to think about
... intent invocation is a navigation transition in the tab
... that's a fruitful way to think about this
... there's also a big implication to the api
... the current API isn't navigational
... there are a lot of exciting aspects
... i'm not sure if we should model it as navigation
... those are the implications for normative part of spec
... if we want to go with a different api
... if a user frequently goes to Flickr
... that's a suggestion that they have a photo they're about to save
... if you visited Flickr 60 times in the past month
... that's at the top of the list
... a web site could say
... i want to use this site for Email, Photo Sharing, Saving Documents, Editing Pictures
... when that gets selected
... that changes the default
... the current experimental prototype
... in 24

<fjh> break until 4 pm (35 min)

Web Activities

mounir: should i show the api?

<mounir> https://wiki.mozilla.org/WebAPI/WebActivities

<mounir> http://lists.w3.org/Archives/Public/public-web-intents/2012Jun/0061.html

mounir: a url for the api, and one explaining why
... we had to do something that looked like web intents for Firefox OS
... we thought Web Intents wasn't the correct solution
... and we needed something fast
... it was close enough
... in my opinion
... one of the issues we had
... Web Intents in the current specification (as of June)
... allowed you to do a lot of stuff
... people were using it to do a lot of stuff
... APIs based on web intents was something we thought shouldn't happen
... if you want a good UI
... you need a constrained UC
... e.g. trying to Run a web Intent that shows nothing
... would be really hard to do
... we tried to restrict that
... Web Activities
... has to have a UI
... we assumed that the UI was clear
... in Firefox OS
... if there's an activity handler
... we show that App for the Activity
... if the activity is doing nothing, user says "what's this app doing" and stop using it
... that Web Intents allowed communication between App A and App B, we tried to prevent that
... in Activity, an Activity returns a value or not
... a UI issue we had
... a new activity
... that was expected to return a value, like Edit
... the UA would have to return that value
... if the value would never be returned, we should fire an error
... to know if the activity would return a value or not, we had to know that
... the boolean for returnValue... is for UI purposes
... we don't have a type attribute in ActivityOptions
... most don't need type
... it was confusing web developers
... if you create an SMS, what type do you pass?
... inventing new types doesn't make sense
... type has to be in the data object
... technical difference in how you create an activity
... the Navigator bit isn't implemented yet
... Web Activity is only implemented for Apps in Firefox OS
... we found issues that are different than what the Chrome team found
... i was telling GregBillock , web activity is interesting for a web os permission thing
... if an app might want to send an sms, it might not want to ask for permissions
... Today, Firefox OS only allows builtin apps to send SMS
... for a trusted app to send an SMS, you have to use an activity (today)
... for permission, you call that actiivity
... we go to the SMS app UI
... so you might understand you're going to send an sms
... and you'd have to press the Send button
... to avoid the user not being aware of sending the sms
... we need the App and Activity to follow this rule
... there were internally issues for this
... for the Telephone activity
... having to press the Green call button
... for security reasons
... even if we put as much restriction we could, we still had to rely on apps to be good citizens
... even more if you give them permissions
... things we found
... GregBillock mentioned window.intent and switching to DOM Event
... for Firefox OS, we're using sendMessage()
... if you send a DOM Event
... making a process to add an activity
... the app might still be open, or might have closed
... i might need to run the app
... if i run the app, and want to send a dom event
... it has to be clear when to send the dom event
... otherwise if the app registers too late, it might miss it
... after load might take a long time
... it was a problem
... too-hard to solve using dom events

s/sendMessage()/System Messages/

scribe: System Messages are like DOM Events
... or window.intent
... it's sent by the system
... if the target isn't awake, the system will wake it
... and those messages will be Queueds

s/ds/d/

scribe: if there's no handler, they'll wait for the handler to come
... the app can check at any time during load
... so they can prepare the UI
... and then they can register for the system message
... when they return to the event loop, we'll call that handler as many time as message are waiting

Josh_Soref: is it a Queue or Stack?

sicking: it's a Queue

mounir: this mechanism is only for Firefox OS
... we will push that in Sys Apps
... we don't know if it will be for regular web content
... what we defined is how to register
... but we haven't implemented it
... we might just use system messages
... regarding Registration
... using Intent inside the body
... right now, Firefox OS just uses the App Manifest
... to register for Activities
... since that isn't for web content
... we haven't decided how to do that
... i'm not a fan of in the <body>, but inside the <head> is understood to be painful

Jungkee: i'm working on two WebIntent specs
... delivering data from server side to client side
... trying to use two activities
... we have many UCs to deliver data from one to another
... in the Pick an Image from the mozilla wiki page

<Josh_Soref> Pick an Image

Jungkee: how do you pick an image if you don't have communication between receiving web app and service
... we want to allow application to application data delivery
... mounir 's explanation in web activities, they don't allow that kind of communication
... ?

mounir: we allow an activity to return a value
... we don't want to allow app A and app B to communicate for an unlimited time frame
... a return value activity in the browser is hard UI wise
... as soon as PostResult is done,
... the UI is simple
... for closing the activity
... if there might be more activity, we don't know how to handle the UI
... what to show is undefined
... there are UCs where people want a View activity for a TV
... and App A controls play-pause
... we think that could be solved w/ another API
... and not activities requiring UI

Jungkee: i understand activities from ui side
... about pick media intent
... have you tried pick media intent/pick contact intent?
... from service page, we're picking contact information/media files

<dom> Pick Media Intent

Jungkee: those two specs are now using picking some data payload
... service to client side

<dom> Pick Contacts Intent

Jungkee: in my opinion right now, we can't avoid some user interaction
... the user interaction between the ui page/tab/window/inline
... to an application page
... that kind of activity is something that i'm thinking about
... we talked about the UC
... we've been working on it w/ some demos
... do you have opinions?

mounir: i'm not sure i understand
... what activities allow you to pick media files?

Jungkee: does it allow ui thing?

mounir: we want to prevent stuff happening in the background w/o UI
... we always want a UI
... if you have a pick activity handled by gallery
... you use pick, gallery handles it
... gallery appears, you interact
... you pick, it returns
... gallery closes
... we implement File Input like that

sicking: we use activities to exactly this flow in Firefox OS
... it is working

fjh: similar question about UI stuff
... in web intents, we use user interaction for privacy/involve user
... do you have interaction as part of it?
... examples don't seem to involve user
... every web activity involves user
... have there been usability issues
... or does it fall out naturally?
... indication that it's usable?
... is usability a concern here?

mounir: we always want a ui
... it's displayed,

dom: does the work flow of Web Activities
... does it work for Users?

mounir: we had a different experience than chrome
... because we only used it for Firefox OS
... but the user experience is very similar to Android
... Android experience isn't awful w/ Intents

fjh: Web Intents lets you have access to resources anywhere
... not just on device

<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?

fjh: request needs some service
... is web activities just the device?

mounir: it's more broad, but right now it's just the device
... there is a registry
... of which apps can handle an activity
... but right now it's limited to installed apps
... if you visit flickr.com, we could add that

<npdoty> ah, I see, so it's just that the registry handler is disabled for non-installed apps?

gmandyam: afaict, when i compared specs side by side
... you aren't depending on Web Messaging
... you didn't want to have Ports, and keeping Ports open was difficult to manage

mounir: we don't use Web Messaging/Ports
... because it's hard to manage UI wise
... we'd be interested in pushing a discovery API
... to allow background services

gmandyam: since web activities works w/o a dependency on web messaging
... and most web intents don't leverage feature of web messaging
... why did we need web messaging?
... maybe it might be better to define intents w/o web messaging?
... until browsers better handle on this problem?

GregBillock: i was going to talk about exactly that
... for Intents, the expected UC is that the structured clone doesn't have ports
... structured clone supports transferables
... but you need Ports to do some of that
... the argument for using structured clone is the same as it has always been
... if interapp communication supports structured clone, it's maximally supported
... you get blobs transferably
... but you can't transfer ports
... you get unpredictably about interaction between contexts
... the right path forward might be to forget structured clones
... we might only support a subset of structured clone
... the difficulties of port exchange are such that it's tempting to not do it
... we might use urls
... and a separate system for some of that
... richt may have an idea
... about Pick Media in Intents v. Activities
... i think it can be trivially over either
... same vocab for both
... some communication mechanism as opposed to more specific
... same problem as Get User Media and Media Pick
... in one, it's "please get me a contact"
... but the application you're talking to, needs some api
... it may use its own contact store (IndexedDB) or its own api over the api
... if there are contact repositories on the device
... there are UCs where you want more high level integration
... sometimes it's useful to have a low level integration api
... apps responsible for receiving it
... need a way to do, e.g. Get User Media
... i'm not sure that having high level means you don't need low level
... just different levels of abstraction

<Zakim> jcdufourd, you wanted to comment on assumption that you can kill the service provider page as soon as it has returned a value

jcdufourd: mounir, you said it isn't ok to pass a message channel as a return from a web activity?
... because you want to be able to kill the service provider when it returns?

mounir: no, it's because i want to know when i'm done w/ the activity
... for the ui
... otherwise we can't build a good ui

jcdufourd: what if you have multiple registrants for an activity?
... what they solved w/ a picker?

mounir: we have a similar UI
... i haven't seen it
... it should look like the Android UI
... to show activity handlers
... we have some security rules
... to prevent activities to register/be open for certain things

sicking: one thing we're cheating
... but because we're only solving on small screen devices
... Chrome is dealing w/ a browser UI
... tabs have a special meaning
... all independent, user is in full control
... all rendered "at the same time"
... we're solving in "you're only showing one app at a time"
... starting an activity replaces the other app
... leaving an app cancels an activity
... we didn't implement this for web pages
... because of UI issues
... a lot of experimenting needs to be done
... i don't think Activities v. Intents makes a lot of difference

nwidell: it sounds like there's technical difficulties to Ports
... long lived
... but by abstracting a lot of interaction parts
... keeping a clean interface between client+server
... we've discussed sensor UCs
... it's a way to connect sensors that may not always be available
... available through some kind of message protocol
... if we remove ports
... we'll need to consider a replacement mechanism
... for long lived

jcdufourd: re sicking
... this isn't implemented for web pages?

sicking: this is only implemented for Firefox OS
... for our Application Platform
... only Installed Applications

<Claes> +1 for nwidell's comment

sicking: can be handlers for Activities
... web pages can invoke a Pick Activity
... but it can't handle one

jcdufourd: you've implemented service providers in HTML/CSS/JS in a browser like context

sicking: i'm distinguishing Web Apps from Web Pages

jcdufourd: only in the context of small screens?
... is it applicable to the wider context of web intents?

sicking: it needs to be experimented with
... we'd have many of the same unsolved questions as Web Intents
... one issue is seeing two tabs rendered
... the first tab is still there
... you can switch between them
... user can open a new web page
... we'd have these problems in Activities

mounir: for us, there's only one App (shown at the same time)
... if an activity is handled of App A
... there's only one instance of App A

<npdoty> the small screen is essentially modal

mounir: if it were to be handled by Flickr.com, which window handles it?
... a new one?

<Zakim> dom, you wanted to interest on background services

dom: thanks, that clarifies a lot of things to me
... i'm not clear if we can converge activities with intents
... not sure if we have hopes for solving the UI
... a separate background API could solve UCs that have been brought up
... i know there are UCs for this
... I know Web Intents was meant to solve this UC
... but it seems it isn't safe to assume that
... should we start forking Intents or,...
... to work on this set of UCs?

GregBillock: initially we called that Hidden Disposition
... like a Web Worker
... that could respond to Web Intent invocations with a result
... requiring no ui surface
... trying to think about how that'd work
... we didn't find a good UI solution for that
... there are definitely reasons it'd be nice to have
... we're not sure how to present that
... for installed apps, it's a bit easier to imagine how it's solved
... there's already a trust for that
... but for web content at large, it's frightening
... to imagine getting access to a sandbox without a task manager
... we haven't cracked that yet

<bryan> +1 to starting discussion on a background service API

mounir: i drafted quickly an api for that
... we haven't implemented it
... and not soon
... if there's interest

dom: that would be a good idea
... not sure about sooner or not
... getting ideas cannot hurt
... it might clarify information re: network discovery proposal
... how these fit/don't together

bryan: that proposal would be one we'd be interested in talking about
... in web & tv, there's interest in using IndexedDB as a filesystem
... but the restriction on origin is problematic
... on an opt in
... to faciliate a virtual file system for web apps
... could be nice

richt: we'll talk about network service discovery tomorrow
... we've talked about ongoing services using urls
... we've looked at allowing a web page to advertise itself as a network service
... but a flag that it's only available on this device
... say for network, or only for device
... it's all client JS
... two tabs
... create background long running communication
... based on URL created by UA
... the URL allows HTTP semantics
... page dies, we can send timeouts
... part of HTTP stuff
... but also flicking a flag to allow other devices to connect
... it's exciting

fjh: thanks, this has been very helpful
... what can we do pragmatically
... GregBillock, you're still working on it?
... mounir, you have a non-contributed spec
... Jungkee mentioned looking at our pick spec
... you said it'd be straightforward
... sicking was saying the UI problem wasn't solved no matter what
... what should we do?

GregBillock: we could come up w/ ideas

<richt> just one minute timeless? I'd be happy to.

GregBillock: but it'd be hard to import into Chrome/Firefox UI process

<richt> s/just one minute timeless? I'd be happy to.//

GregBillock: it isn't a very satisfying message

fjh: it makes sense
... we want wide interop adoption
... will this outcome mean interop implementations?

GregBillock: that's the goal

<richt> Scribe: richt

<dom> scribenick: richt

GregBillock: I think there is commitment there that we can work together on this.
... the optimism is well-founded. It's an encouraging prognosis.

mounir: I agree. Our goal is to have an interoperable implementation.
... we don't want to stay inside walls.

dom: So what are the next steps? actions?

GregBillock: We're going to be talking for sure.
... There are other profitable directions to think about.
... We need to think about some of the ideas like navigation.
... Some of the things richt was talking about reminded me of that.
... e.g. HTTP semantics.
... 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.

dom: Another question. A lot of people have heard about Web Intents. We have a Working Draft.
... Only very few will hear about the discussions we've had over the last few days.
... What can we do with the existing draft to make it clear where we are at with this?

GregBillock: It's on us (the draft editors) that current status is correctly reflected.
... and the way to make progress here.
... That is all going to be happening soon.
... We wanted to talk in DAP about this stuff before we sent all that info out.
... Make sure we're saying things that the WG is agreeing on.

fjh: If GregBillock and mounir could discuss this soon then we could put out a collaboration announcement aka. making progress on this stuff.

GregBillock: We've put our implementation behind a flag. There's still a lot of thinking and problem-solving going on
... We'll see what the outcome will be here.
... Part of that whole process will be based on discussion we have on the mailing list.

nwidell: Require a clarification: Are we removing long-life connectivity from Web Intents?

s/long-life/long-lived/

fjh: Presume we wouldn't need another mailing list for this?

dom: That's in scope for DAP

fjh: What would happen to the work you're doing richt

richt: We've been coming at this from a different angle...
... 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.
... we'll be talking about that soon and hope to add something to the spec there so there may be some overlap.

Agenda review

fjh: I've updated the agenda for tomorrow.

,,, Start time is currently 9am.

<timeless> s/,,,/.../

fjh: On request we're moving Network Service Discovery to the morning session.
... After lunch we'll be talking about signage, pick media and calendar.
... We'll be briefly talking about Media Capture and Sensors.

<timeless> /me looks like around 9am

fjh: We wanted to talk about CoreMob a little also.

<timeless> s| /me looks like around 9am||

dom: We have a few people in the room that are also involved in CoreMob.

fjh: At the request of Cathy (due to TZ differences) could we move Network Service Discovery to just after lunch?

<npdoty> I don't think lunch is served until 12:30

fjh: so 1pm CET tomorrow.

[ negotiating a time to talk about NSD tomorrow ]

scribe: we'll start at 1.30pm CET tomorrow

s/... so 1pm CET tomorrow.//

Cathy: Works for me.
... we'll start Network Service Discovery discussion at 1pm CET tomorrow

s/... we'll start at 1.30pm CET tomorrow//

Agenda for tomorrow: http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France

Jungkee: Do we have 30 minutes left to talk about Pick Contacts Intent spec?

fjh: Probably not time today.

Jungkee: Hope to get consensus tomorrow in the meeting. I would like to show a Pick Media demo now.

[ Jungkee makes a demo of the Pick Media Intents Addendum API http://www.w3.org/TR/2012/WD-gallery-20120712/ ]

<npdoty> that confusion is indeed an excellent example of the UI problem discussed earlier

<dom> hmm... is it? (it does illustrate a potential problem, but not sure that matches the one previously discussed)

<Josh_Soref> sort of

<Josh_Soref> in average use, the client and service would have very different visual style and content

<dom> right

<Josh_Soref> and the service would show content relating to what it's likely to offer

<dom> (a potential problem would be a provider trying to blur that distinction)

<Josh_Soref> whereas the client would have stuff relating to what it was trying to do (and thus that it needed something)

<npdoty> can the user tell the difference between an Intent that is in progress and creating a new tab via window.open()?

<dom> ah ok, fair point

<timeless> npdoty: at this point there is a ui indicator in Chrome

<timeless> specifically the urlbar has a "change provider" button

<timeless> beyond that, not really

<timeless> plus, i'm envisioning intermediate Intents

<timeless> which are both services and clients

<timeless> e.g. if i want to pick - video/mpeg

<timeless> and i have a "make video from slideshow" intent

<timeless> s/timeless/Josh_Soref/

<timeless> s/timeless/Josh_Soref/

<timeless> s/timeless/Josh_Soref/

<timeless> s/timeless/Josh_Soref/

<timeless> s/timeless/Josh_Soref/

<timeless> s/timeless/Josh_Soref/

<timeless> s/timeless/Josh_Soref/

fjh: We'll take a break then we'll have some discussion about privacy.

dom: Sounds good but I don't want to get in to the discussion about e.g. specific fields in my address book.
... that could get too complicated.

s/fjh: We'll take a break then we'll have some discussion about privacy./fjh: We'll have some discussion about privacy tomorrow./

<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|

Jungkee: meta data provided by Pick Contents would be very useful for a lot of services.
... Now I'll quickly show the Pick Contacts Intent demo.

[ Jungkee shows a demo of the Pick Contacts Intent Addendum API http://www.w3.org/TR/contacts-api/ ]

Thanks Jungkee

npdoty: We have an informal meet-up tonight with privacy folks for a few drinks for those interested.

fjh: Anything else we need to do today?

<npdoty> privacy get together at 7pm downstairs in the lobby, drinks and maybe dinner too

<npdoty> everything will be off the record, thx dom

[ reviewing today's actions ]

<fjh> Thanks for scribing Josh, Rich and Bryan!

[ meeting closed for the day ]

<fjh> ACTION: gbillock to work with mounir to create new webintents draft that reflects web activities and issues [recorded in http://www.w3.org/2012/11/01-dap-minutes.html#action07]

<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].

<fjh> ACTION: mounir to Work with Greg to create new webintents draft that reflects web activities and issues [recorded in http://www.w3.org/2012/11/01-dap-minutes.html#action08]

<timeless> s/aaa:/noriya:/

<timeless> s/ddd:/jsoh:/

<timeless> s/eee:/dnkim:/

<timeless> s/hhh: (missed all that)/daniel_samsung: Soonhong Daniel Park, Samsung/

<timeless> s/iii: from ETRI/skim: Sung Hei Kim from ETRI/

<timeless> s/Geun-Hyung_Kim/Geun-Hyung_Kim_(comus)/

<timeless> s/yungkee/jungkee/

<timeless> s/rss generate minute//

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Teleconference/F2F/
Succeeded: s/ccc:/Yoshiharu Dewa:/
Succeeded: s/guiseppe/giuseppe/
Succeeded: s/bbb:/sato/
Succeeded: s/ggg/Harald_Alvestrand/
Succeeded: s/jjj/wook hyun/
Succeeded: s/soonbo:/shan: Soonbo Han/
Succeeded: s/kkk/shingak kang/
Succeeded: s/trackbot, RRSAgent//
FAILED: s|Sorry, dom, I don't understand 'trackbot, RRSAgent'. Please refer to http://www.w3.org/2005/06/tracker/irc for help.||
Succeeded: s/scribenick bryan//
Succeeded: s/Yoshiharu Dewa:/Yoshiharu_Dewa:/
Succeeded: s/wook hyun:/wook_hyun:/
Succeeded: s/shingak kang:/shingak_kang:/
Succeeded: s/giri:/gmandyam:/
Succeeded: s/Niklas:/Claes:/
Succeeded: s/sato from Sony/sato: Sato, Sony/
Succeeded: s/sato from Sony//
Succeeded: s/Yoshiharu_Dewa:/Yoshiharu_Dewa: Yoshiharu Dewa, Sony/
Succeeded: s/giuseppe:/giuseppe: Giuseppe Pascale/
Succeeded: s/Harald_Alvestrand: from Google/Harald_Alvestrand: Harald Alvestrand, Google/
Succeeded: s/fff: from KDDI/Hidetoshi: Hidetoshi Yokota from KDDI/
Succeeded: s/fff->Hidetoshi Yokota from KDDI//
Succeeded: s/Claes: from Sony, editing/nwidell: Niklas Widell from Sony, editing/
Succeeded: s/nwidell: Niklas Widell from Sony, editing/Claes: Claes Nilsson from Sony, editing/
Succeeded: s/Claes: from Ericsson/nwidell: Niklas Widell, from Ericsson/
Succeeded: s/jcdufourd:/jcdufourd: Xjcdufourd/
Succeeded: s/jcdufourd: Xjcdufourd/jcdufourXd: Xjcdufourd/
Succeeded: s/jcdufourd:/jcdufourd: Xjcdufourd/
FAILED: s/jcdufourXd: jcdufourd/jcdufourd: /
Succeeded: s|s/jcdufourXd: jcdufourd/jcdufourd: /||
Succeeded: s/jcdufourXd: Xjcdufourd/jcdufourd: /
Succeeded: s/suites/suite/
Succeeded: s/Xjcdufourd/Jean-Claude Dufourd/
Succeeded: s/Dom: back/dom: Dominique Hazael-Massieux, w3/
Succeeded: s/Present+ noriya sakamoto from toshiba/Present+ Noriya_Sakamoto/
Succeeded: s/Present+ Geun-Hyung KIm/Present+ Geun-Hyung_KIm/
Succeeded: s/Present+ Jong Soo Oh/Present+ Jong_Soo_Oh/
Succeeded: s/Donyun_Kim/Donyun Kim/
Succeeded: s/Present+ sato/Present+ Naoyuki_Sato/
Succeeded: s/CR/PR/
Succeeded: s/kensaku from/Kensaku Komatsu from/
Succeeded: s/kensaku/X_X_X/
Succeeded: s/kensaku//
Succeeded: s/X_X_X/kensaku/
Succeeded: s/yungkee/jungkee/
Succeeded: s/kensaku/scribe/
Succeeded: s/Kensaku Komatsu/kensaku: Kensaku Komatsu/
Succeeded: s/dnkim/scribe/
Succeeded: s/Donyun Kim/dnkim: Donyun Kim/
Succeeded: s/skim/scribe/
Succeeded: s/Sung Hei Kim/SKim: Sung Hei Kim/
Succeeded: s/jsoh/scribe/
Succeeded: s/JongSoo_Oh, LGE/jsoh: JongSoo_Oh, LGE/
Succeeded: s/youenn fablet/Youenn Fablet/
Succeeded: s/youenn/scribe/
Succeeded: s/Youenn Fablet/youenn: Youenn Fablet/
Succeeded: s/+q/q+/
Succeeded: s/mounir:/mo_unir:/
Succeeded: s/mounir/scribe/
Succeeded: s/mo_unir:/mounir:/
Succeeded: s/reported/reported (it's ok, for the UA battery report to indicate dying sooner, but not ok to report dying after the OS)/
Succeeded: s/kick in/kick in in REC/
Succeeded: s|a/ackfjh//||
Succeeded: s|ackfjh||
Succeeded: s|heard about a blackberry implementation|-> https://developer.blackberry.com/html5/apis/blackberry.system.html#.event:batterystatus "BlackBerry 10" implementation|
Succeeded: s/Juan_J/Yuan_J/
Succeeded: s/C/CR/
Succeeded: s/shipping/shipping to leave CR/
Succeeded: s/josh:/Josh_Soref:/G
Succeeded: s/josh_soref:/Josh_Soref:/G
Succeeded: s/fjh/scribe/
Succeeded: s/fjh/scribe/
Succeeded: s/I propose/fjh: I propose/
Succeeded: s/clarify/fjh: clarify/
FAILED: 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 Audio WG concerns with HTML Media Capture API|
Succeeded: s/capture/camera/
FAILED: s/experiment -- and it fails -- miserably//
FAILED: s/cameraq/camera/
Succeeded: s/its/it's/
FAILED: 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./
Succeeded: s/Josh_Soref/scribe/
FAILED: s/rename it to "HTML Media File Capture/ rename it for clarity, possibly HTML Media File capture/
FAILED: s/rename/consider renaming/
FAILED: s/CFC/CfC/
FAILED: i/vibration and wrap/Topic: Vibration
FAILED: i/proximity and ambient light sensors/Topic: proximity and ambient light sensors
Succeeded: s/Josh_Soref/timeless/
Succeeded: s/Josh_Soref/timeless/
Succeeded: s/Josh_Soref/timeless/
Succeeded: s/Josh_Soref/timeless/
Succeeded: s/Josh_Soref/timeless/
Succeeded: s/Josh_Soref/timeless/
FAILED: s/incresaes/increases/
FAILED: s/it's not fork the resources based on bandwidth/it's not fork the user experience based on bandwidth/
Succeeded: s/+q/q+/G
FAILED: s/???/as they can get this information/
FAILED: s/needed/needed to some network providers/
FAILED: s/needed/needed to some network providers/
FAILED: s/../.../
FAILED: s/goood/good/
FAILED: s/be less/be less, if the radio only turns on once/
FAILED: s/source/src/
FAILED: s/src set/srcset/
FAILED: s/?//
FAILED: s/syste/system/
FAILED: s/ack claes//
FAILED: s/ack//
FAILED: s/sendMessage()/System Messages/
FAILED: s/ds/d/
FAILED: s/just one minute timeless? I'd be happy to.//
FAILED: s/long-life/long-lived/
FAILED: s/,,,/.../
FAILED: s| /me looks like around 9am||
FAILED: s/... so 1pm CET tomorrow.//
FAILED: s/... we'll start at 1.30pm CET tomorrow//
FAILED: s/timeless/Josh_Soref/
FAILED: s/timeless/Josh_Soref/
FAILED: s/timeless/Josh_Soref/
FAILED: s/timeless/Josh_Soref/
FAILED: s/timeless/Josh_Soref/
FAILED: s/timeless/Josh_Soref/
FAILED: s/timeless/Josh_Soref/
FAILED: s/fjh: We'll take a break then we'll have some discussion about privacy./fjh: We'll have some discussion about privacy tomorrow./
FAILED: 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|
Succeeded: s/giri:/gmandyam:/g
Succeeded: s/claes:/Claes:/g
Succeeded: s/anssi:/AnssiK:/g
Succeeded: s/anssik:/AnssiK:/g
Succeeded: s/jcdofourd:/jcdufourd:/g
Succeeded: s/jungkee:/Jungkee:/g
Succeeded: s/wonsuk:/Wonsuk:/g
FAILED: s/aaa:/noriya:/
FAILED: s/ddd:/jsoh:/
FAILED: s/eee:/dnkim:/
FAILED: s/hhh: (missed all that)/daniel_samsung: Soonhong Daniel Park, Samsung/
FAILED: s/iii: from ETRI/skim: Sung Hei Kim from ETRI/
FAILED: s/Geun-Hyung_Kim/Geun-Hyung_Kim_(comus)/
FAILED: s/yungkee/jungkee/
FAILED: s/rss generate minute//
Found ScribeNick: bryan
Found Scribe: timeless
Inferring ScribeNick: timeless
Found Scribe: richt
Found ScribeNick: richt
Scribes: timeless, richt
ScribeNicks: bryan, timeless, richt
Default Present: Salon_pasteur, +1.781.266.aaaa, cathy, Cathy_Chan
Present: Adrian_Bateman Anssi_Kostiainen Bryan_Sullivan Cathy_Chan Claes_Nilsson Dominique_Hazael-Massieux Donyun_Kim Doug_Schepers_(shepazu) Eduardo_Fullea Frederick_Hirsch Geun-Hyung_Kim Giri_Mandyam GregBillock Harald_Alvestrand Hiroyuki_Aizu Jean-Claude_Dufourd Jinhong_Yong Jonas_Sicking Jonathan_Jeon JongSoo_Oh Josh_Soref Jungkee_Song Kensaku_Komatsu Milan_Patel Mounir_Lamouri Naoyuki_Sato Niklas_Widell Noriya_Sakamoto Rich_Tibbett Sakari_Poussa Salon_pasteur Shin-Gak_Kang Soonbo_Han Sung_Hei_Kim Suresh_Chitturi Sylvain_Lalande Travis_Leithead Wonsuk_Lee Wook_Hyun Yoshiharu_Dewa Yuan_Ji giuseppe jerome_giraud Nick_Doty Hidetoshi_Yokota Olivier_Thereaux Youenn_Fablet Soonhong_Daniel_Park
Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France
Found Date: 01 Nov 2012
Guessing minutes URL: http://www.w3.org/2012/11/01-dap-minutes.html
People with action items: anssi dom fjh gbillock mounir richt