# TPAC 2010 F2F Meeting - Day 2 ## 05 Nov 2010 [Agenda][3] ## Attendees Present Johnson_W, Robin_Berjon, Frederick_Hirsch, Anssi_Kostiainen, Ilkka_Oksanen, Laszlo_Gombos, Marco_Marengo, Kai_Hendry, jerome_giraud, Ingmar_Kliche, Claes_Nilsson, Suresh_Chitturi, Soonho_Lee, YounSung_Chu, Niklas_Widell, Jesus_Martin, Rich_Tibbett, Maria_Oteo, youenn, Kangchan_Lee, Wonsuk_Lee, Hiroyuki_Aizu, ManYoung_Cho, Cecile_Marc, Bryan_Sullivan;, Daniel_Coloma, Dong-Young_Lee, Doug_Sheppers, Dominique_Hazael-Massieux, Koan- Sin_Tan Regrets Chair Robin_Berjon, Frederick_Hirsch Scribe lgombos_, Claes, dsr, richt ## Contents * [Topics][4] 1. [testing][5] 2. [Metaphors for write-back and deletion][6] 3. [Phono][7] 4. [Dan Burnett on Phono][8] 5. [Device element][9] 6. [Capture API][10] 7. [Messaging][11] 8. [Next F2F][12] 9. [App Launcher][13] 10. [Wrap up][14] * [Summary of Action Items][15] * * * trackbot-ng, start telecon Date: 05 November 2010 ScribeNick: lgombos_ ### testing AnssiK: Testing is important. ... PhoneGap started to prototyping DAP APIs ... PhoneGap using QUnit and Mobile Spec ACTION-287? ACTION-287 -- Anssi Kostiainen to introduce phonegap tests during F2F -- due 2010-10-27 -- OPEN [http://www.w3.org/2009/dap/track/actions/287][16] [http://docs.jquery.com/Qunit][17] AnssiK: QUnit is a generic test framework; not jQuery specific [http://github.com/phonegap/mobile- spec/blob/master/tests/contacts.tests.js][18] AnssiK: Pros fro QUnit - used by high profile project and well tested I'll let Dom explain testing at W3C AnssiK: not clear how to do interactive tests with QUnit drogersuk: WAC forked QUnit called QUnite could synthesize events to test with UI for known cases? drogersuk: explain test descriptors (XML based); used to automate test richt: test harness proposed for HTML5 is from opera, but it is meant for all browser and should allow automation +1 on aligning with HTML/WebApps richt: prefers to use the same test infra for DAP as for WebApps/HTML ... there is also a templating system (I'll be talking about the test assertion methodology, fwiw) richt: test infra can generate QUnit tests drogersuk: key is the standardization on the automation syntax we can agree on the test methodology here. markup assertions in the specifications. produce a test-suite. produce an xml descriptor file and test case resource URLs. ack fjh, you wanted to suggest NoInterfaceObject IDL then we can apply a templating system and run testing with our automated test tool or apply a qUnit test templating system. ...so we can probably agree on everything up to the qUnit part. but if I had to choose today I'd prefer to use the testharness as used in WebApps and HTML WGs. AnssiK: walks trough a few test assertions [[http://suika.fam.cx/www/webidl2tests/readme][19] is a tool that produces test cases on WebIDL, but is not up to date wrt WebIDL] richt: internal system to generate qunit tests from WebIDL ... need a link between the spec and qUnit Opera's WebIDL to test stub generator would be super useful for testing device APIs [http://www.w3.org/2010/11/04-html-wg2-minutes.html][20] hendry: reftests, automated tests and manual tests ... process for reviewing and approving tests ref tests are good for testing UI and could work for Device API testing PROPOSED RESOLUTION: Base our tests on the HTML/WebApps JavaScript test harness fjh: we probably do not want to handcraft tests that could be derived from WebIDL richt: specs and testsuites really belong together dom, do we have a W3C DAP repo for testing device APIs? Topics to be discussed with regard to testing: which specs should we start building tests, what kind of editing conventions, where to host test cases not yet, hendry [ debate about whether editors should write tests or not -- chairs don't agree with richt ] drogersuk: WAC has a priority list for tests (functional, boundary, etc..) [I've started a wiki page on our testing efforts [http://www.w3.org/2009/dap/wiki/Testing][21] ] dom, you wanted to comment on automation drogersuk: is there an arch for testing in W3C ? for the record, good specifications happen when the editors are aware of the testing needs. dom: let's resolve webapps/html testing within w3c and try to intruduce that perhaps to other W3C specs/groups who maintains the test harness in W3C? would like W3C to standardise on automation syntax for testing At Opera we also like atomic testing of requirements. One test case page per requirement where possible (for automated reporting purposes) [http://www.w3.org/TR/test-methodology/#relationship-to-the- standardization-process][22] [http://www.w3.org/TR/test-methodology/][23] <- Dom's link -> Produces the following: [http://dev.w3.org/2006/waf/widgets/test-suite/][24] ...which let's us make the following -> [http://dev.w3.org/2006/waf/widgets/imp-report/][25] [http://www.w3.org/TR/test-methodology/][23] this requires editors to create normative statements against defined targets in a very specific manner to enable subsequent test case generation dom: explains the test methodology - from spec to test assertions to test suite/test run and test reports looking at dom's diagram, I suggest that the test plan is in a structured format such as xml (what we call a tests descriptor file). This also allows for capture of tests which may not even be in the scope of the suite / may not be written dom: we have less experience of testing apis than testing formats ...automation should come later in the process ..shouldn't invest too early as could complicate the process fjh: test methodology has an impact on how we actually write specs ... are specs have MUST and SHOULD ? dom: key is to link a section of spec to a set of tests Topics to be discussed with regard to testing: which specs should we start building tests, what kind of editing conventions, where to host test cases It may be good to apply this to Contacts. **ACTION:** Dom to work with rich on test-enabling the contacts API [recorded in [http://www.w3.org/2010/11/05-dap-minutes.html#action01][26]] Created ACTION-298 - Work with rich on test-enabling the contacts API [on Dominique Hazaël-Massieux - due 2010-11-12]. PROPOSED RESOLUTION: Base our tests on the HTML/WebApps JavaScript test harness dom: do we host on cvs or mercurial server ... prefers mercurial fjh, you wanted to ask about test methodology close ACTION-287 ACTION-287 Introduce phonegap tests during F2F closed close ACTION-288 ACTION-288 Introduce testing@w3c during F2F closed ### Metaphors for write-back and deletion ISSUE-97? ISSUE-97 -- Write-access difficulties (in contacts and other APIs), see [http://lists.w3.org/Archives/Public/public-device- apis/2010Jul/0112.html][27] -- raised [http://www.w3.org/2009/dap/track/issues/97][28] [http://lists.w3.org/Archives/Public/public-device- apis/2010Nov/0002.html][29] richt: can we apply the save (download) paradigm to contacts API richt, you serious about new URI scheme? agreement to not do a separate contact URI scheme, follow File API. Separate question about what URI scheme to use in File API. richt: essentially one would download a contact bryan: drag&drop? ... drag&drop is another paradigm - drop here to save tihngs icon on the browser chrome ? darobin: we can have several ui paadigm ... environment can make a decision based on mimetype discussion on formulating the problem we'd like to solve what about updating existing contacts? darobin: also need a mechanism for conflict resolution on write-back bryan: once you have a contact reference one should be able to drop it, delete it, save it..etc - need a way to have a reference to one contact rigo, you wanted to express concern about the meaning of the message richt: one common use-case is to have a phone number on the page that is clickable and allows saving the number as a new contact possible privacy concern with saving to unexpected location? rigo: reusing dialogs could be confusing if now they have a new meaning fjh, you wanted to ask what we are trying to decide richt: we're trying to design the api that fits "browser context" darobin: deleting and managing contacts perhaps is not focus robin notes argument is that creating a contact is useful from the web yet managing existing contacts including updates and delete can be managed locally we made a resolution yesterday that we would focus on things that make sense in the standard web browser context. [have we made any progress on format-based saving rather than API based- saving?] create, edit, update/save are core features cf ACTION-230 ACTION-230? ACTION-230 -- Wojciech Maslowski to specify "add to calendar" based on ICS-objects opening -- due 2010-08-05 -- OPEN [http://www.w3.org/2009/dap/track/actions/230][30] darobin: why do we redirect to blob ? ... this means we need a serialized format dom: same was discussed for calendar richt: uri gives as e.g. drag&drop ... other option is save as a trusted event focusing on "what makes sense in the standard web browser context" does not mean that every API function accessible to web applications needs to be implemented directly in the browser (e.g. thus requiring the browser to implement the contact delete function itself, or "delete" operations in general), but that the browser provides a bridge to the device resource which manages the related resource/data. Thus even if there is no typical UI paradigm for "delete" the browser can enable an application to use that function as provided by the contacts manager accessed through the API. anssi's testing slides -> [http://lists.w3.org/Archives/Public/public- device-apis/2010Nov/0016.html][31] **ACTION:** Richard to draft a Contacts Saving ED [recorded in [http://www.w3.org/2010/11/05-dap-minutes.html#action02][32]] Created ACTION-299 - Draft a Contacts Saving ED [on Richard Tibbett - due 2010-11-12]. ScribeNick: Claes ### Phono ### Dan Burnett on Phono Dan Burnett from Voxeo scribe: Want to present a list of things that this group could pay attention to. ... Build Tropo ... common set of scripting API for interactive phone apps ... a phone in the browser [Phono slides presented by Dan Burnett][33] ÷here scribe: phono is a jquery plugin [PhonoSDK Kitchen Sink Demo][34] scribe: wheather app demo by placing a phone call Ansi: : Can we get rid of flash? Dan: No, not yet. ... We need: ... better streaming API ... Mic and camera access ... echo cancellation Robin: Relation to element? ... we request use cases Ingmar: the screen sharing use case is an interesting use case that we hadn't considered for Capture before Dan: We will proide formal requirements dsr, you wanted to ask about whether use cases for peer to peer connections have been considered? dom: screen sharing could be done by making your own screen one of the capture sources Dsr: Peer-to-peer use cases? Dan: Phono to phono could potentially be done peer-to-peer ... Streaming through http has different latency issues. DSR: web sockets can help with latency and get through firewalls via port 80 ### Device element waiting for Doug Sheppers the WG start chanting "Doug! Doug! Doug! Doug! Doug! Doug! Doug! Doug!" 4We Want Doug! We Want Doug! We Want Doug! We Want Doug! We Want Doug! We Want Doug! We Want Doug! [http://www.whatwg.org/specs/web-apps/current- work/complete/commands.html#devices][35] Robin: Device element is a way to do the video conf use case ... associated API to start, stop steram ... set up a connection peer ... Ericsson has made a demo Ericsson's implementation of : [https://labs.ericsson.com /developer-community/blog/beyond-html5-implementing-device-and-stream- management-webkit][36] Robin: step back and state our reqs on want this group want to do Doug: Advice this group to move ahead with this ... communicate with various groups that could have useful input on device ... collection use cases good idea Robin: We are cool :-) Doug: There are technical solutions ... Need to go forward quickly ... we can't say that is the way forward. Basic problem is access to stream from "devices" Ericsson and Sony Ericsson willing to help scribe: viedeo and audio elements might be enough richt: we assume that works. we have different ideas e.g. [http://dev.w3.org/2009/dap/contacts/Overview.html#sharing-contact-information ---example--2][37] scribe: thanks does not add anything to HTML. It requires Javascript to function. Another approach is to invoke a JS API via...JS: [http://dev.w3.org/2009/dap/contacts/Overview.html#api-invocation-via-dom- events][38] ...(link included as an example of an early generic idea/concept) richt, fwiw, I think it does bring more than an API would; e.g. a non programmatic , UI based device-selector sounds a good thing to explore Robin: IETF may be interested in creating a protocol for streaming audio, video, etc. dom, absolutely, it does make sense to explore and Opera is also looking in to it. also, I've heard many times many browsers developers saying they prefer having a DOM anchor to Web APIs as much as possible a little concerned on the implications of pursuing this work in terms of group's priority and scoping **ACTION:** claes to start working on use cases and requirements for video/audio conference à la element [recorded in [http://www.w3.org/2010/11/05-dap-minutes.html#action03][39]] Created ACTION-300 - Start working on use cases and requirements for video/audio conference à la element [on Claes Nilsson - due 2010-11-12]. dom, I can agree with that view. We could conversely do more to make the element useful without javascript (and then use the Javascript stuff much like the File API works on a useful HTML element) +1 Robin: Hope we can do this without inventing a new element Richt: Participation on this? ... recharter needed? ... we want to get browser vendors participate special Task force sound like a good approach to avoid the re- chartering problem and "other" issues after lunch, capture then messaging, plan to resume at 13:30 [PrimeLife Privacy Dashboard][40] [http://www.primelife.eu/results/opensource/76-dashboard][40] p David Raggett presented Privacy Dashboard approach next step is for this project to become open source ScribeNick: dsr Dave Raggett shows 2 demo's one on a privacy dashboard that allows users to view how websites are collecting and to set per site preferences ### Capture API the second demo was on a fresh take on P3P with simplified semantics [http://mozillalabs.com/rainbow/2010/10/28/cloud-meet-rainbow/][41] [ dashboard at [http://www.primelife.eu/results/opensource][42] ] [Mozilla rainbox example][43] dsr, interesting demos. I have a number of questions but I'll explore further later. The canvas element can be used as a "viewfinder" for the media stream via the Capture API. You can capture the media to a file object. [http://dev.w3.org/2009/dap/camera/][44] (so the interfaces are window.navigator.service.media.record() and window.navigator.service.media.stop() ) can you open the bridge, please? thanks ilkka: any comments on the capture API document? Robin: Microsoft had some, let me know if you haven't got them We need to coordinate with the HTML WG, we've sent them this document for review. dom: only remaining unaddressed comment for HTML Media Capture regards the serialization of the codecs description Ilkka switches to the media capture document ... we may want to move this to LC sooner rather than later [http://www.w3.org/TR/media-capture-api][45] Some open issues for review Changed name of attribute to MediaFileData (I hope we'll discuss alignment with Mozilla's API?) for supported formats for images, video and audio We should provide an explanation of why there are two capture specifications Ilkka: this is historical and we started with JavaScript APIs Rich: it is going to be difficult to explain the differences between the specs. Dom: the specs are complementary ... would like to discuss alignment with Mozilla work (Rainbow) Rich: with a bit of cleaning up, we could drop the need for the device element and align the models. Robin: the differences are significant Suresh and Ilkka discuss some of the details. Bryan: one difference is how to report supported codec types. I think the The Media Capture API is a prime target for defining the Stream interface currently in the spec. It says it needs a better home in the spec at the moment... In the HTML version users could be asked to select the codec/format, Ilkka's spec does provide the developer with some degree of control over the codecs. The capture API complements the HTML Form media capturing spec with a means for scripts to start a capture process for adding a clip to the form. Rich: this could be extended to support live streaming as a well as capture to a file object. General agreement of the need for real time interface including streaming. Robin: should we merge streaming into [http://dev.w3.org/2009/dap/camera /Overview-API.html][46] ? Rich: no, it shouldn't be a bolt on Bryan: showing the viewfinder and assigning it to a stream are two separate things, right? Rich: no, we can use the same method for assigning the stream to the viewfinder (canvas element) and to other sinks The Stream API for the device element provides the means to assign a stream to a URI sink or to a video element/canvas element Dave asks clarification question. Rich explains that currently we have URL for source of a stream but not for the sink This is because we are concerned here with capturing media to a file object for later transmission as part of a form. [http://dev.w3.org/2009/dap/camera/Overview-API.html#introduction][47] says "It completes the HTML Form Based Media Capturing specification [HTMLMEDIACAPTURE] with a programmatic access to start a parametrized capture process." This spec does provide for a live view of the camera viewfinder, but the media is directed to a file object and not to a stream as such. s/inveting/inventing/ Robin: we need to provide an explanation of the role of the two media capture specifications to reduce the chance of confusion. HTML Media Capture and Capture API are similar... dom: the difference between the two is that the media API is parametrizable, while the other is a very thin layer on top of HTML file input ...the first integrates Video/Audio capture in to the HTML file input element. The Capture API allows programmatic access to acheive the same thing... ...however the Capture API allows options to be sent to the camera... ...but both APIs do NOT stream data back to the web page... ....that is the purpose of the element (today). HTML Media Capture and Capture API return a File object. returns a Stream object that contains a 'url' attribute that can be assigned to a