<fjh> trackbot-ng, start telecon
<trackbot> Date: 05 November 2010
<lgombos_> ScribeNick: lgombos_
AnssiK: Testing is important.
... PhoneGap started to prototyping DAP APIs
... PhoneGap using QUnit and Mobile Spec
<dom> ACTION-287?
<trackbot> ACTION-287 -- Anssi Kostiainen to introduce phonegap tests during F2F -- due 2010-10-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/287
<fjh> http://docs.jquery.com/Qunit
AnssiK: QUnit is a generic test framework; not jQuery specific
<AnssiK> http://github.com/phonegap/mobile-spec/blob/master/tests/contacts.tests.js
AnssiK: Pros fro QUnit - used by high profile project and well tested
<richt> I'll let Dom explain testing at W3C
AnssiK: not clear how to do interactive tests with QUnit
drogersuk: WAC forked QUnit called QUnite
<fjh> 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
<dom> +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
<dom> (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
<richt> 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.
<fjh> ack
<Zakim> fjh, you wanted to suggest NoInterfaceObject IDL
<richt> then we can apply a templating system and run testing with our automated test tool or apply a qUnit test templating system.
<richt> ...so we can probably agree on everything up to the qUnit part.
<richt> 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
<dom> [http://suika.fam.cx/www/webidl2tests/readme 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
<hendry> Opera's WebIDL to test stub generator would be super useful for testing device APIs
<hendry> http://www.w3.org/2010/11/04-html-wg2-minutes.html
hendry: reftests, automated tests and manual tests
... process for reviewing and approving tests
<richt> ref tests are good for testing UI and could work for Device API testing
<dom> 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
<hendry> dom, do we have a W3C DAP repo for testing device APIs?
<dom> 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
<dom> not yet, hendry
<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..)
<dom> [I've started a wiki page on our testing efforts http://www.w3.org/2009/dap/wiki/Testing ]
<Zakim> dom, you wanted to comment on automation
drogersuk: is there an arch for testing in W3C ?
<richt> 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
<fjh> who maintains the test harness in W3C?
<drogersuk> would like W3C to standardise on automation syntax for testing
<richt> At Opera we also like atomic testing of requirements. One test case page per requirement where possible (for automated reporting purposes)
<dom> http://www.w3.org/TR/test-methodology/#relationship-to-the-standardization-process
<richt> http://www.w3.org/TR/test-methodology/
<richt> <- Dom's link
<richt> -> Produces the following:
<richt> http://dev.w3.org/2006/waf/widgets/test-suite/
<richt> ...which let's us make the following ->
<richt> http://dev.w3.org/2006/waf/widgets/imp-report/
<fjh> http://www.w3.org/TR/test-methodology/
<fjh> 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
<drogersuk> 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
<drogersuk> dom: we have less experience of testing apis than testing formats
<drogersuk> ...automation should come later in the process
<drogersuk> ..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
<dom> 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
<richt> It may be good to apply this to Contacts.
<dom> 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]
<trackbot> Created ACTION-298 - Work with rich on test-enabling the contacts API [on Dominique Hazaël-Massieux - due 2010-11-12].
<dom> PROPOSED RESOLUTION: Base our tests on the HTML/WebApps JavaScript test harness
dom: do we host on cvs or mercurial server
... prefers mercurial
<Zakim> fjh, you wanted to ask about test methodology
<dom> close ACTION-287
<trackbot> ACTION-287 Introduce phonegap tests during F2F closed
<dom> close ACTION-288
<trackbot> ACTION-288 Introduce testing@w3c during F2F closed
<dom> ISSUE-97?
<trackbot> ISSUE-97 -- Write-access difficulties (in contacts and other APIs), see http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0112.html -- raised
<trackbot> http://www.w3.org/2009/dap/track/issues/97
<richt> http://lists.w3.org/Archives/Public/public-device-apis/2010Nov/0002.html
richt: can we apply the save (download) paradigm to contacts API
<tlr> richt, you serious about new URI scheme?
<tlr> 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
<nwidell> 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
<Zakim> 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
<fjh> possible privacy concern with saving to unexpected location?
rigo: reusing dialogs could be confusing if now they have a new meaning
<Zakim> 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
<fjh> 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
<richt> we made a resolution yesterday that we would focus on things that make sense in the standard web browser context.
<dom> [have we made any progress on format-based saving rather than API based-saving?]
<Suresh> create, edit, update/save are core features
<dom> cf ACTION-230
<dom> ACTION-230?
<trackbot> ACTION-230 -- Wojciech Maslowski to specify "add to calendar" based on ICS-objects opening -- due 2010-08-05 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/230
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
<bryan> 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
<bryan> "delete" the browser can enable an application to use that function as provided by the contacts manager accessed through the API.
<fjh> anssi's testing slides -> http://lists.w3.org/Archives/Public/public-device-apis/2010Nov/0016.html
<darobin> ACTION: Richard to draft a Contacts Saving ED [recorded in http://www.w3.org/2010/11/05-dap-minutes.html#action02]
<trackbot> Created ACTION-299 - Draft a Contacts Saving ED [on Richard Tibbett - due 2010-11-12].
<Claes> ScribeNick: Claes
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
<dom> Phono slides presented by Dan Burnett
<darobin> ÷here
scribe: phono is a jquery plugin
<dom> PhonoSDK Kitchen Sink Demo
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 <device> element?
... we request use cases
<dom> 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
<Zakim> dsr, you wanted to ask about whether use cases for peer to peer connections have been considered?
<dom> 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> DSR: web sockets can help with latency and get through firewalls via port 80
waiting for Doug Sheppers
<darobin> the WG start chanting "Doug! Doug! Doug! Doug! Doug! Doug! Doug! Doug!"
<darobin> 4We Want Doug! We Want Doug! We Want Doug! We Want Doug! We Want Doug! We Want Doug! We Want Doug!
<ilkka> http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html#devices
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
<richt> Ericsson's implementation of <device>: https://labs.ericsson.com/developer-community/blog/beyond-html5-implementing-device-and-stream-management-webkit
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 <device> 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> richt: we assume that <device> works. we have different ideas e.g. http://dev.w3.org/2009/dap/contacts/Overview.html#sharing-contact-information---example--2
scribe: thanks
<richt> <device> 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
<richt> ...(link included as an example of an early generic idea/concept)
<dom> 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.
<richt> dom, absolutely, it does make sense to explore and Opera is also looking in to it.
<dom> also, I've heard many times many browsers developers saying they prefer having a DOM anchor to Web APIs as much as possible
<Suresh> a little concerned on the implications of pursuing this work in terms of group's priority and scoping
<dom> ACTION: claes to start working on use cases and requirements for video/audio conference à la <device> element [recorded in http://www.w3.org/2010/11/05-dap-minutes.html#action03]
<trackbot> Created ACTION-300 - Start working on use cases and requirements for video/audio conference à la <device> element [on Claes Nilsson - due 2010-11-12].
<richt> dom, I can agree with that view. We could conversely do more to make the <device> element useful without javascript (and then use the Javascript stuff much like the File API works on a useful HTML element)
<dom> +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
<Suresh> special Task force sound like a good approach to avoid the re-chartering problem and "other" issues
<fjh> after lunch, capture then messaging,
<fjh> plan to resume at 13:30
<dom> PrimeLife Privacy Dashboard
<darobin> http://www.primelife.eu/results/opensource/76-dashboard
<fjh> p
<fjh> David Raggett presented Privacy Dashboard approach
<fjh> next step is for this project to become open source
<dsr> 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
the second demo was on a fresh take on P3P with simplified semantics
<ilkka> http://mozillalabs.com/rainbow/2010/10/28/cloud-meet-rainbow/
[ dashboard at http://www.primelife.eu/results/opensource ]
<dom> Mozilla rainbox example
<richt> 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.
<ilkka> http://dev.w3.org/2009/dap/camera/
<dom> (so the interfaces are window.navigator.service.media.record() and window.navigator.service.media.stop() )
<danielcoloma> can you open the bridge, please?
<danielcoloma> 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> dom: only remaining unaddressed comment for HTML Media Capture regards the serialization of the codecs description
Ilkka switches to the media capture document
<dom> ... we may want to move this to LC sooner rather than later
http://www.w3.org/TR/media-capture-api
Some open issues for review
Changed name of attribute to MediaFileData
<dom> (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.
<richt> I think the The Media Capture API is a prime target for defining the Stream interface currently in the <device> spec. It says it needs a better home in the <device> 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 ?
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.
<dom> http://dev.w3.org/2009/dap/camera/Overview-API.html#introduction 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.
<fjh> 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.
<richt> HTML Media Capture and Capture API are similar...
<dom> 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
<richt> ...the first integrates Video/Audio capture in to the HTML file input element. The Capture API allows programmatic access to acheive the same thing...
<richt> ...however the Capture API allows options to be sent to the camera...
<richt> ...but both APIs do NOT stream data back to the web page...
<richt> ....that is the purpose of the <device> element (today).
<richt> HTML Media Capture and Capture API return a File object. <device> returns a Stream object that contains a 'url' attribute that can be assigned to a <video> element (or other suitable element)
Bryan talks about the options in the Capture API (CaptureVideoOptions)
<richt> ...therefore the url attribute enables a <video> element to act as the camera viewfinder.
The HTML media captuure offers users the choice of capturing a clip from the camera (as seen in the video element acting as the viewfinder) or for picking a previously recorded clip via a file picker.
Robin: can we move the Media Capture API to Last Call as http://www.w3.org/TR/media-capture-api/ ??
Rich explains that some browsers don't offer the viewfinder interface.
Dom: you could trigger the viewfinder by default when the capture parameter is set, and have a button there to switch to normal file picker; or have two buttons in the web page, one for normal file picker, the other for viewfinder
<scribe> ACTION: Robin to issue a CFC for the media capture API [recorded in http://www.w3.org/2010/11/05-dap-minutes.html#action04]
<trackbot> Created ACTION-301 - Issue a CFC for the media capture API [on Robin Berjon - due 2010-11-12].
<dom> (not media capture API, HTML Media Capture; will correct the action)
Ilkka prepares to leave ...
<richt> dsr wrote: "The HTML media captuure offers users the choice of capturing a clip from the camera (as seen in the video element acting as the viewfinder) or for picking a previously recorded clip via a file picker."...
Suresh: Maria had a couple of issues on the list
<richt> ...this is not the case (see my description of relationship of the specs above)
[link to the emails?]
<dom> (I think given our latest view on sticking with default browser model, we should vastly simplify the messaging API and remove its most scary capabilities)
Rich: do you want to prompt every time you send a message?
You don't see the text that will be sent by a script which could be a problem.
Dom: proposes to have just a few additional features to the URI scheme and perhaps a call back when the message has been sent
We should start by separating sending from subscription
<danielcoloma> not fully hearing what is being said by Dom
<danielcoloma> is the proposal to remove the JS API and replace it by URI extensions?
<dom> dom: adding an API that has similar functionalities as what the URI schemes allow plus a few additional bonus (e.g. having attachments, callback on success sending) would probably work the best
Rich: you will get different user experiences on different platforms (as always)
<danielcoloma> +1 to dom suggestion
[ http://dev.w3.org/2009/dap/messaging/ ]
<richt> A messaging API or using scheme uris such as sms: will produce the exact same result....
<richt> ...a user MUST be able to review messages being sent from their device.
<richt> ....policy does not save you on that front.
<richt> ...the result is to display the SMS to the user for them to approve and click 'send' or cancel and click 'cancel'
Suresh: what are the concerns about providing a JavaScript API?
Dom: it would be JavaScript API, but with a clearer security model.
Email would be sent through a native app.
Rich: we could register for the email MIME type to handle email if so desired.
... we don't need an email for sending, a URI is sufficient
Dom: we've been discussing an API which adds a few features to the URI, e.g. call back and attachments.
Rich: will browser vendors implement that?
Robin outlines a proposal from the top of his head ...
a URI from a blob ...
<darobin> generate a mailto URI from a Blob
<darobin> the blob is MIME that is the body of the mail
<darobin> seems mad, just suggesting as a possible option
Frederic: attachments are an important use case, right?
Let's progress this to CR, and if it doesn't get implementations it dies
<Suresh> +1
Test cases can be generated during CR and we don't need to do that before.
<fjh> I hear rough consensus to proceed with an API that enables attachments
<danielcoloma> +1
Bryan: we need to align what is done here in W3C with what is done elsewhere e.g. WAC, see http://public.wholesaleappcommunity.com/redmine/embedded/wac2pubrev/deviceapis/messaging.html
We review the list of editors for our messaging spec
<richt> I'm not involved in Messaging API for sending SMS, MMS or Email from this point forward. I have proposed the URI model and a Generic Push Notification API. http://lists.w3.org/Archives/Public/public-device-apis/2010Nov/0004.html
<Suresh> I would prefer find() feature over subscription
<Suresh> assuming we agree to keep the send and creation in the API
<dom> ACTION: Maria to morph Messaging API into an API that wraps URI schemes options and adds attachment/success callback, and split off subscription [recorded in http://www.w3.org/2010/11/05-dap-minutes.html#action05]
<trackbot> Created ACTION-302 - Morph Messaging API into an API that wraps URI schemes options and adds attachment/success callback, and split off subscription [on Maria Angeles Oteo - due 2010-11-12].
Rich: are we interested in richer notifications for incoming messages?
<richt> Are we interested in a generic server-sent notifications system rather than having to implement the same thing just for SMS, MMS and Email?
<dom> dom: one good thing about the new proposed API model is that don't need to worry about a specific permission model for it: user accepts sending by pressing the send button of her usual messaging interface
<Suresh> PROPOSED Resolution: Proceed with Messaging API with basic functionality (create, send, read/find) desgined to fit the web pardigms
<richt> disagree
<dom> PROPOSED Resolution: Proceed with Messaging API with basic functionality (create, send) designed
<richt> PROPOSED RESOLUTION: Proceed with Messaging API that a.) creates a Blob SMS URI for adding attachments and b.) Allows for a callback to return the sending success or failure.
<dom> PROPOSED Resolution: Proceed with Messaging API with basic functionality (create, send) with attachments and success callback
<danielcoloma> cannot hear you
<danielcoloma> but the last (I hope) resolution suggested by Dom is OK with me
<Suresh> +1 to proposed resolution
RESOLUTION: Proceed with Messaging API with basic functionality (create, send) with attachments and success callback
<dom> s/<dom> RESOLUTION/<dsr> RESOLUTION/
<richt> I can live with it but I do not support this specification due to alternative mechanisms being available.
<richt> ScribeNick: richt
fjh: too early to decide exact date...maybe provide an indication of the date. What month are we talking about?
dom: F2F in March 2011 and a meeting at TPAC 2011.
fjh: Perhaps we need 1 F2F in between those two meetings?
dom: June or July
<darobin> ACTION: Robin to send a request for hosting [recorded in http://www.w3.org/2010/11/05-dap-minutes.html#action06]
<trackbot> Created ACTION-303 - Send a request for hosting [on Robin Berjon - due 2010-11-12].
dom: We need to make a plan for next year as soon as possible.
<dom> ACTION: Richard to investigate hosting a meeting in June/July in Opera's European offices [recorded in http://www.w3.org/2010/11/05-dap-minutes.html#action07]
<trackbot> Created ACTION-304 - Investigate hosting a meeting in June/July in Opera's European offices [on Richard Tibbett - due 2010-11-12].
Kangchan: we will have a 1-day workshop in Seoul as well as the F2F. Hope DAP members will present at this workshop. Program coming soon.
<scribe> ACTION: Kangchan to provide details of workshop at Seoul F2F (March 2011) [recorded in http://www.w3.org/2010/11/05-dap-minutes.html#action08]
<trackbot> Created ACTION-305 - Provide details of workshop at Seoul F2F (March 2011) [on Kangchan Lee - due 2010-11-12].
Kangchan: If people need visa, please contact me for this.
如果人们需要签证，请联系这个样子。
<fjh> If you are from China or India you may need a visa for Korea, please check into this.
<darobin> यदि आप एक वीसा की जरूरत है कृपया हमसे संपर्क करें. :)
bryan: In WAC, App Launcher includes things we can launch by URI scheme
<fjh> http://dev.w3.org/2009/dap/app-launcher/
bryan: The system defines who handles a certain scheme or document type.
darobin: when the current app does not find its handler it goes to the system for this info.
bryan: You may find that what you want to do is not supported by the browser.
... If I want to view a PDF then I may want to launch a specific application on the device.
<dom> [I don't think use case 3 should be addressed by an API, but by browsers UI directly]
<dom> s/brwo/brow/
bryan: The browser should be able to launch a specific external application to launch that e.g. document
<darobin> Ես ոչ մի մարդագայլ, մի հասարակ գյուղացու.
<dom> [one use case that I could see would be to detect whether a browser has any registered handler for a given URI scheme or mime type]
bryan: If I have a storefront and I want to purchase/upgrade something then I need to ability to invoke a specific application.
... currently we have no way of doing that.
... HTML5 allows us to define handlers but it doesn't extend to this use case.
<fjh> rrsagent. generate minutes
<darobin> [use case 3 could be handled by the File API, associating a media type with a blob URI]
bryan: [goes through the App Launcher API interfaces]
fjh: There's a risk on an environment where you don't want to launch items that could pose a security risk
bryan: the user is involved in the decision of what happens.
dom: I'm not convinced by most of the use cases
... Something that may be useful is to know if we have a defined handler for a given mime-type in the browser.
... Anything where we try to launch a specific application, that worries me a bit.
... I don't want to introduce paths to do that.
... We should leave to the browser interface anything that is related to the URI scheme.
... This API is a shortcut to things that browsers already do.
bryan: I'm not sure I agree.
dom: Go to a website, website registers to handle myscheme: uri and then the website handles that.
... Instead of just websites, a dialog pops up and the user can pick the intended application.
... this is not desktop vs. mobile.
bryan: trust in the app delivery chain is essential. It's something we are delivering in WAC.
dom: Beyond the mobile platform you don't have this. You don't have this on every platform.
... Let's not go there.
... the question is 'what are the features we want to develop'?.
... what are the use cases we actually want to enable.
... this can be set in the UA.
... maybe there are hooks that enable the dialog discussed above. I want to see user stories and use cases.
... that make sense in the UA (both mobile and desktop).
... we want to augment the web platform.
Suresh: Firstly, the App Launcher API allows us to wrap URIs. The second is two invoke based on Application ID.
... In the mobile, switching between apps is a big challenge. If we can switch directly to an application it may be user friendly.
fjh: so it's a usability issue to doing this.
Suresh: yes
bryan: we'd like to see this stuff supported because it is not today.
... we have use cases that AT&T, ETRI, WAC feel are valid.
... we will have the ability to support this across all platforms.
fjh: this leaves us to address security issues.
<dom> [WAC 1.0 doesn't include app launcher AFAICT]
bryan: we ask the user 'Do you want to launch the app?'
dom: the first part of the API, wrapping URIs, is redundant.
... the second part, targetting a specific executable, is not currently addressed
... there is no way to start a new application in the browser. Just use the URI or MIME type to launch an application.
... launching a specific application is a security risk. The webapp needs some knowledge of what applications are available on the device.
... that's a huge security risk.
bryan: why is this API being held to a higher standard for security than other APIs?
robin: it isn't
fjh: by adding this API we are expanding the attack surface.
... You're saying it doesn't matter because we already have it in a number of places
dom: beyond the security stuff, my main problem with the spec is the importance of the use cases rather than the API. Are the use cases important?
<wonsuk> [When we use the native UIs from browsers, most of UIs are different. so it's not convenient to the users. for example, Video Players of browsers, so i think that so far many HTML5 Video Players are coming. which could be show the same UI to the users independent of the user's browser.]
richt: we're not going to implement this. I wouldn't be able to sell this internally or externally.
... the URI scheme works today. If it's absolutely mandatory to target a specific application then you could specify a custom URI scheme.
... like spotify and itunes for example.
fjh: so we have differences of opinion. What do we do? What are the benefits of standardization of this?
darobin: We can defer this. Let another consortium take this on.
dom: This needs to be done on the list. We can work on use cases that define the need for the feature and then decide if we need an API.
freedom: maybe you could limit it to the mobile phone case.
... there may be security constraints.
fjh: having it in the general browser is the objective. bryan is suggesting that there are different needs on mobile.
bryan: we can try to work on the use cases and perhaps narrow the scope also.
dom: currently there is app launching, app setting and info read on apps.
... ...
... we need to be clear on the use cases for those.
<dom> robin: one thing we could look at is a vibrate() API
fjh: Are we done?
... Individuals can go through their actions from the meetings.
<dom> Next call: November 17
fjh: Cancelling the conference call scheduled for 24th November.
RESOLUTION: Cancelling the conference call scheduled for 24th November.
darobin: We are adjouned.
[room applauds, cries a little bit and collapses back in their chairs]