See also: IRC log
<trackbot> Date: 20 July 2011
<fjh> trackbot, start telecon
<trackbot> Meeting: Device APIs and Policy Working Group Teleconference
<trackbot> Date: 20 July 2011
<fjh> Chair: Robin_Berjon, Frederick_Hirsch
<francois> Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_19,_20,_21_July_2011,_Paris
<fjh> ScribeNick: ingmar
<robin> scribe: ernesto_jimenez
<robin> scribenick: ernesto_jimenez
francois: We would like to change the situation where each WG handles its own testing. We are about to create a testing activity with a testing interest group and probably a working group
... the testing interest group will be the place to discuss testing and tools, and we'll be developing the framework for the groups to develop their own tests
... if people are interested in joining or taking a role in that activity, please get in touch
<francois> Draft charter of the Browser Testing IG (not under review yet): http://www.w3.org/2011/05/testing-ig-charter.html
francois: the group hasn't been formalized yet, but it should be soon
<francois> Draft charter of the Browser Testing and Tools WG (not yet under review): http://www.w3.org/2011/08/browser-testing-charter.html
<francois> public-test-infra
francois: we have a public mailing list called public-test-infra
<robin> http://lists.w3.org/Archives/Public/public-test-infra/
francois: the interest group is to work in the framework and the working group is to work on the web driver area (browser simulation)
... you will soon receive formal links to review the charter
... in the mean time we have been reviewing the existing testing frameworks and we have decided to start working with the CSS framework
... I would encourage you to adapt DAP tests and use the framework
fjh: I've seen the charter and it looks like this only affects to browser tests
francois: yes, we have focused on browser testing because it's more common across different working groups
robin: in terms of tooling, is everything pretty much open?
<francois> Draft Testing requirements: http://www.w3.org/wiki/Testing/Requirements
francois: yes, everything is open right now, we started a wiki
... with an architecture with the testing framework we want and we already got some suggestions
... the main goal is to test specifications
robin: talking about tools that will allow to generate tests from the spec given certain markup
<robin> http://www.w3.org/TR/test-methodology/
francois: we want to start having WG developing tests and writing the specs with testable assertions, in the long term we would like to have the test generation from the spec, but it's a long term goal
robin: talking about the document on how to write testable conformance requirements
bryan: it would be good to have some resources in W3C to assist working groups on their testing activities
francois: we'll need the resources, we need support to get the resources
robin: have you started talking with external organizations?
<robin> http://www.mosquito-fp7.eu/
francois: not yet, we have had a contact with ETSI and we will collaborate with them to work in an open interop event
... they are working in interop through testing with the mosquito project
robin: have you talked to WAC?
francois: some people in the interest group have been in WAC. The difference with WAC and other orgs is that they do testing for certification and we don't want to do certification in the W3C
<robin> also http://tests.wacapps.net/
francois: but we want to create test suites that can be extracted into other test suites
... the difficulty is to find a common set that works for different organizations and companies
Youngsun: asks about TV testing?
<robin> http://seleniumhq.org/
francois: there has been some talk on the Web & TV about a testing framework suitable for TV and extracting some parts of the HTML5 tests, but the focus right now is on browsers
bryan: asks about selenium
francois: explains what selenium is and what it does
... we want testing for different browsers, not only desktop, and we want to create a web driver standard that applies to browsers for different devices
robin: there's support for selenium in some mobile browsers
ernesto: the problem is that it's a hack, so it'll be nice to have an standard API
francois: that's the idea, to create an standard API to do web driver testing
robin: will it include screen captures?
francois: I don't think it's part on the web driver API, but I would suggest that you suggest to add screen capture in the charter of the working group
bryan: asks about the interop event
<wonsuk> WebDriver For Mobile Browsers: http://code.google.com/p/selenium/wiki/WebDriverForMobileBrowsers
francois: says it'll probably be in december, in Europe and probably with more focus on mobile because of the people involved
bryan: when you say it's about testing browsers, does that include widget runtimes?
francois: yes
bryan: so the charter will say the focus will be in browsers and widget runtimes?
francois: says the charter doesn't mention widget runtimes explicitly right now, he suggests bryan to do the suggestion when he reviews the charter
robin: asks if the IG will be open
francois: it's not official yet, so it cannot be confirmed. with the charter as it is now, it will be open
<robin> http://w3c-test.org/dap/contacts/tests/
<robin> hg clone https://dvcs.w3.org/hg/dap
robin: is introducing the contacts test suite
<robin> http://w3c-test.org/dap/contacts/tests/test-suite.xml
<robin> http://dev.w3.org/2006/waf/widgets-api/imp-report/
robin: asking if anybody is interested in developing tests in the WG
<robin> http://dev.w3.org/2009/dap/messaging/
robin: introducing the messaging API
<robin> http://www.w3.org/mid/181FCCA2-77C2-4206-80EA-67379BD28175@berjon.com
robin: there was an issue where you could not know what protocol was available, so a new design was suggested
<robin> <a href='mailto:robin@berjon.com'>
<robin> .addAttachments()
<robin> <a href='xmpp:robin@berjon.com'>
robin: where you will have an addAttachments method that would only be available for protocols that support attachments
... mailto would have an .addAttachments() method, but xmpp wouldn't
bryan: clarifying that it's not about finding if a protocol has support for attachments, but finding out what messaging protocols are supported in the browser (mail, sms, xmpp)
<robin> ACTION: Robin to review Messaging for publication [recorded in http://www.w3.org/2011/07/20-dap-minutes.html#action01]
<trackbot> Created ACTION-431 - Review Messaging for publication [on Robin Berjon - due 2011-07-27].
<ingmar> scribe: ingmar
<robin> scribenick: ingmar
<robin> http://www.w3.org/mid/1306417721.3237.194.camel@altostratustier
there is no technical work to be done at the moment on HTML Media Capture
robin: question is about how to move on with Media Capture API
... coordination call with WebRTC, WebRTC would work on the streaming and media handling as discussed yesterday
<robin> http://dev.w3.org/2009/dap/camera/Overview-API
robin: current Media Capture API could be developed further towards camera control (flash etc)
robin: this proposal handles streaming, but not e.g. zooming
bryan: if we decide to drop the media capture api we should ask the group
robin: the media capture api with zooming etc should work together with the streaming api
... the problem might be that the media capture api might just be a replacement of the systems capturing capability
... the media capture api provides a few advantages over HTML media capture, such as format and length settings, but this might not be enough for a separate spec
bryan: the most interesting use case is to show a video as a preview inside an HTML page, record it and send it to the server (e.g. social media side)
robin: this could be achieved with the web-apps proposal
... we agreed in Seoul to rely on whatever WebRTC will do on codecs
ingmar: capturing/recording would be covered by the web-apps/webrtc proposal, what would be the benefit of DAPs media capture api? Camera control?
robin: video and audio recording would be covered by webrtc, but taking pictures presumably not
... the question remains if there is room for another spec between HTML media capture and the streaming API of webrtc
ernesto: what is the status of HTML media capture?
robin: it should be stable, need some discussion with HTML wg
<francois> [probably worth dropping the note in the introduction that says "The Working Group is investigating the opportunity to specify streaming access via the proposed <device> element."]
<robin> issue: HTML Media Capture doesn't make sense if accept=image and capture=microphone
<trackbot> Created ISSUE-116 - HTML Media Capture doesn't make sense if accept=image and capture=microphone ; please complete additional details at http://www.w3.org/2009/dap/track/issues/116/edit .
<robin> issue: Should HTML Media Capture have options for front/user camera as in getUserMedia
<trackbot> Created ISSUE-117 - Should HTML Media Capture have options for front/user camera as in getUserMedia ; please complete additional details at http://www.w3.org/2009/dap/track/issues/117/edit .
<robin> ACTION: Ernesto to make a proposal for ISSUE-116 and ISSUE-117 [recorded in http://www.w3.org/2011/07/20-dap-minutes.html#action02]
<trackbot> Created ACTION-432 - Make a proposal for ISSUE-116 and ISSUE-117 [on Ernesto Jimenez - due 2011-07-27].
robin: there doesn't seem to be huge interest in continuing media capture api
... we might want to think about use cases such as zooming or other camera control and observe the API proposal of WebRTC
<robin> http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
lgombos__: this spec is used by the WebNotification spec
<lgombos__> permissions feedback - http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0042.html
<robin> http://berjon.com/blog/2011/06/numerical-constants-must-die.html
<Josh_Soref> (webapps and html-wg are moving to numerical constants)
<robin> RESOLUTION: Switch to string constants
<robin> ... because existing implementations are vendor prefixed
lgombos__: I noticed that SysInfo has the same issue
... if we make this change in permissions api we should also make it in other specs
<fjh> discussion on whether this functionality be available from workers
<lgombos__> made the following changes to the spec; added [NoInterfaceObject] to the Permissions interface; renamed Navigator to NavigatorPermissions
robin: the default for a new spec should be "not available from workers"
<robin> ACTION: Laszlo to reply to Anne about his Permissions questions [recorded in http://www.w3.org/2011/07/20-dap-minutes.html#action03]
<trackbot> Created ACTION-433 - Reply to Anne about his Permissions questions [on Laszlo Gombos - due 2011-07-27].
<Josh_Soref> permissionLevel would be better as permissionLevelFor
<Josh_Soref> robin suggests permissionLevel would be better as permissionFor
<robin> http://www.w3.org/TR/api-perms/
robin: we leave the names as is
<robin> http://wiki.whatwg.org/wiki/RelExtensions
<Josh_Soref> [ http://dev.w3.org/2009/dap/api-perms/ ]
robin: future specs should define their strings, but we probably need a document for existing specs
... the only legacy spec seems to be geolocation
Josh_Soref: how about versioning?
<robin> http://www.w3.org/2005/04/xpointer-schemes/
<robin> ACTION: Dom to investigate if DAP could use the XPointer registration code for feature registration [recorded in http://www.w3.org/2011/07/20-dap-minutes.html#action04]
<trackbot> Created ACTION-434 - Investigate if DAP could use the XPointer registration code for feature registration [on Dominique Hazaël-Massieux - due 2011-07-27].
robin: will send the conclusions of the discussion to the group mailing list later
... when could we go to FPWD?
<Josh_Soref> [ robin captures action items necessary before FPWD ]
Josh_Soref: what needs to be done is to copy over the prefix paragraph, mention that there is a registration process, create legacy list, recommendation on when distinct feature names might be needed for granularity
<robin> ACTION: Laszlo to update the Permissions draft based on f2f discussion and summary email from Robin in planning for FPWD, due 2011-09-01 [recorded in http://www.w3.org/2011/07/20-dap-minutes.html#action05]
<trackbot> Created ACTION-435 - Update the Permissions draft based on f2f discussion and summary email from Robin in planning for FPWD, due 2011-09-01 [on Laszlo Gombos - due 2011-07-27].
<robin> action-435?
<trackbot> ACTION-435 -- Laszlo Gombos to update the Permissions draft based on f2f discussion and summary email from Robin in planning for FPWD, due 2011-09-01 -- due 2011-07-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/435
<Josh_Soref> We probably want a testable example permission which can be used for testing the specification
<robin> ACTION: Wonsuk to provide an example for Permissions [recorded in http://www.w3.org/2011/07/20-dap-minutes.html#action06]
<trackbot> Created ACTION-436 - Provide an example for Permissions [on WonSuk Lee - due 2011-07-27].
<francois> scribe: cmarc
<robin> ScribeNick: cmarc
<richt> could someone prod me when the agenda moves to Web & TV? ...
<richt> ... I have a number of things to do before I go on vacation tomorrow for a few weeks so regrets that I can't attend the whole meeting.
<robin> http://dev.w3.org/2009/dap/netinfo/
robin: has feedback from ingmar
... the problem is the cost information
Status in wac or gsma?
look in android 2 types
wifi and ..
Is it useful to have detail 2G, 3G?
<Josh_Soref> [ http://developer.android.com/reference/android/net/ConnectivityManager.html ]
bryan: mobile or wifi should be sufficient
<robin> http://davidbcalhoun.com/2010/using-navigator-connection-android
<Josh_Soref> [ http://developer.android.com/reference/android/net/NetworkInfo.html ]
josh: care about roaming
if the apps can know your cost ..
<Josh_Soref> public String getTypeName () Return a human-readable name describe the type of the network, for example "WIFI" or "MOBILE".
robin: cost is quite impossible to specify
... the problem is that roaming is not deterministic for cost
... it depends on operators, regions
... too difficult to quantify
... [ Robin opens the bridge ]
... subject cost and network info
<Josh_Soref> robin informs us that there are places one can roam to where you'd be paying less than your home area
robin: There is an operator in Africa who offer the same price for 5 countries.
... section 4, multiple online events
... can be an issue
... it might trigger quite regularly
... an event is fired if you change from 2G to 3G for example
... and it can change very often
bryan: it is not relevant to have 2G, 3G and so many details
robin: so at the end is this API useful at all?
... the idea was : if they are different versions (optimized) of site, benefit to the good one
... Is there any active usage of this API?
... Phonegap has an implementation.
... BlackBerry as well.
josh: we should find out what is used
Google's Android api is not documented
<robin> http://www.mobilexweb.com/blog/android-froyo-html5-accelerometer-flash-player
robin: should we talk to google people about that
<robin> ACTION: Laszlo to talk to the Android people about whether the Netinfo API is used and something they think was a good idea [recorded in http://www.w3.org/2011/07/20-dap-minutes.html#action07]
<trackbot> Created ACTION-437 - Talk to the Android people about whether the Netinfo API is used and something they think was a good idea [on Laszlo Gombos - due 2011-07-27].
bryan: how can we use it if not documented ?
josh: good question, but it is common in mobile (and sadly even non-mobile) web
<robin> ACTION: Josh to talk to Brian Leroux about the Netinfo API in PhoneGap to ask about uptake and feedback [recorded in http://www.w3.org/2011/07/20-dap-minutes.html#action08]
<trackbot> Created ACTION-438 - Talk to Brian Leroux about the Netinfo API in PhoneGap to ask about uptake and feedback [on Josh Soref - due 2011-07-27].
robin: we can freeze implementation on it
josh: sensors the apis on deviceorientation ...
use case : use a device as a mouse
proximity sensor
robin: if people have use cases,on it
josh: has it to be managed at the app level or platform level? platform
laszlo: which event should be managed by the page?
robin: should someone take an action to look at use cases, see what is relevant?
<Josh_Soref> Feedback from others has been about wanting to get information from medical sensors
<Josh_Soref> Our response to them was to try using a local websocket source to translate the information for use by web apps
<Josh_Soref> It might make sense to have a NOTE suggesting something like that to people interested in exposing sensors
<robin> ACTION: Bryan to draft use cases for proximity, ambient light, and ambient sound sensors. [recorded in http://www.w3.org/2011/07/20-dap-minutes.html#action09]
<trackbot> Created ACTION-439 - Draft use cases for proximity, ambient light, and ambient sound sensors. [on Bryan Sullivan - due 2011-07-27].
write all the ideas about sensors
ernesto: it depends on sensors, we need something consistent for accelerometer for example
robin: maybe Claes wanted to propose something
<robin> [FWIW in http://www.w3.org/mid/6DFA1B20D858A14488A66D6EEDF26AA34D4885808D@seldmbx03.corpusers.net Claes talks about using Web Introducer for generic sensors]
robin: there was no deployed implementation in bondi
... implemented probably but not deployed ...
basically, if you don't trust websites...
overall sysinfo status spec is not moving
<robin> http://web-send.org/introducer/
robin: WebIntroducer is in dap group
... it is in the charter
... people involved in that document may join the group (in discussion)
<francois> Web and TV IG wiki: http://www.w3.org/2011/webtv/wiki/Main_Page
Francois: it is an interest group, don't develop standards
... [the wiki?] was created following the workshop.
the third workshop will occur in west coast in september
<francois> CfP for 3rd workshop: http://www.w3.org/2011/09/webtv/
(first in japan, second was in berlin)
it was in february this year
discuss about needs for convergence between web and tv
(not tv on web, or web on tv)
mediapipeline task force: extend video tag
other topics adaptive streaming over http
accessibility issues
emergency issues
two active TF: home networking task force
and mediapipeline TF
robin: HbbTV [www.hbbtv.org]? involved
national, regional organization involved
many companies, broadcasters, etc..
Francois: some are invited to join dap
... as the subject they are interested in are in this group;
... so that they work also on deliverables.
... TV is an important device, DAP is about mobile, desktop, TV, etc..
... there is not point to have a web and TV working group.
... One topic discussed is device discovery
... because TV is often the middle of other devices (at home)
... Device discovery is in DAP's new [proposed] charter
... (charter is waiting for management approval-soon).
... The home network TF is producing use cases and requirements.
... DAP could use those use cases and requirements
... the participants of the TF are encouraged to move to WG ...
... to contribute here in DAP.
robin: the discovery has a lot of synergy with dap other works
but if this does not work out... we will have to find something else
<robin> --- break ---
<francois> scribe: francois
<robin> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0073.html
rich: I'll present an introduction to how I see things here.
<robin> http://people.opera.com/richt/release/specs/discovery/Overview.html
rich: Giuseppe Pascale is chair of ... The home network TF within the Web and TV IG. They have been working on use cases and requirements.
... Opera proposed an API. Took a few months to design it. A lot of Giuseppe's opinions were formed based on internal discussions at Opera.
... Large ecosystem of devices we produce systems for (game consoles, desktop, mobiles, TVs, ...)
... interest to have these devices communicate.
... This proposal allows a Web page running on a domain to discover, connect and communicate with home network devices.
... Local network services.
... This proposal exposes these services.
... We looked at the different service discovery protocols, mDNS, UPnP.
... Initially, we thought we'd need separate interfaces for each.
... We found a way to merge them.
... Half-way at least.
... The details of the discovery protocols are left away.
... The proposal supports UPnP (SSDP) and mDNS (zeroconf).
... We kept removing stuff rather than adding stuff.
... We found a level of abstraction which is very low but allows to use different discovery protocols.
... That suits local network use cases because there is not much agreement on top of device discovery protocols.
... There is no real standard for communication.
... The service endpoint within devices becomes first-class URI for that service. Whitelisted. Same-origin.
... Discussed briefly in the Web and TV IG.
... which will still produce a use cases and requirements document which may affect some of this. We wanted to prototype, hence the submission.
... We submitted it to get feedback to see if we're doing it in a sane way. To obtain feedback early. There's good chance that some of it will change significantly but we'll handle it with vendor prefixes.
<ingmar> [http://people.opera.com/richt/release/specs/discovery/Overview.html]
rich: For it to be a success and attract new participants in DAP to work on this, separation of work items in DAP is very important. Email tagging is essential.
... Once we have that, the hope is that people from Web and TV will join DAP.
... The idea is to collect the technical people within DAP to pursue this proposal.
... Note it's just a proposal, nothing set in stone.
... That doesn't preclude other proposals.
... Feedback welcome on device API list.
robin: thanks for the introduction.
<Zakim> fjh_, you wanted to ask a few questions about the discovery spec
fjh: I assume that you're not mandating UPnP or zeroconf. I'm not sure whether we should keep details about how to use it with those protocols.
rich: we have discussed this internally and externally. Interesting one. Do we mandate both? Or do we leave things unspecified?
... For prototyping at Opera, we'll handle both.
... The level of details in the proposal was meant to remove ambiguity, to improve interoperability.
fjh: the UA maintains the table, consistently polling what's around. I guess there's a battery performance concern here.
rich: the UA can do that initially, or when the API is called. Everything's asynchronous in the API.
fjh: when you use this API, do you have to know what mechanism is underneath?
rich: it's transparent, but you, as a Web developer, can precise a given UPnP service.
... the API pushes a lot of the logic into JavaScript.
fjh: so the developer needs to have an understanding of what's going on underneath.
rich: yes.
robin: you mention implementing, prototyping. Any progress?
rich: nothing public yet, but top priority.
robin: have you talked with guys behind Web Introducer? I was wondering if there was a way to make both things work together. Local network is one thing, but it might happen that the service is remote.
rich: the current process will search the local domain for services. What you can do is specify a remote domain and scan for services there. Possible with DNS-SD.
... The Web Introducer is somewhat parallel, there are points that may need connecting. That would be next step.
robin: any concerns about UPnP and interoperability?
<robin> [certification costs money]
rich: yes. UPnP suffers from fragmentation. That's what we don't want to embed a complete UPnP library in the browser.
<Zakim> Cathy, you wanted to get clarifications on discovery
rich: That's why we push things to JavaScript.
Cathy: do you foresee if you just do all the UPnP discovery in the background?
<Josh_Soref> [ scribe lost bits; richt suggested that javascript libraries would be written and maintained to handle specific profiles ]
[ scribe also missed technical discussion between Cathy and Rich ]
Cathy: my concern is that we're suggesting browser vendors to do discovery in the background. If you have a lot of devices in the network sending periodic notifications, then lots of messages will need to be processed.
rich: yes, we'll handle that if needed
Cathy: the steps on discovery implies that the UA has to perform discovery in the background. Need to clarify how steps might be different if discovery happens only on invocation of the API.
rich: once you get a service in a Web page, you don't care how you got it. What matters is what you can do with it.
robin: you mentioned other spec you had a look at. Do you mean Dave Raggett's one?
rich: yes and other internal proposals.
robin: the current API does whitelisting of services. Have you considered CORS?
rich: yes, that's an interesting angle.
... We don't want to replicate the billions of devices that exist in the network.
... The problem with CORS is that if you want to have access, you have to add domains or IP address you want to add access to.
... You could have * which is a very bad idea in a local network context.
... You don't know the IP address of the computer in the local network as it appears to other devices.
... Having said that, CORS could work. If we could get CORS to work in the local network, we could use it.
... The main problem with this API is that UPnP is inherently insecure.
... [Other solutions mentioned such as the one used in Google TV]
... In short, changes are required to CORS.
<Josh_Soref> ack
<Zakim> Josh_Soref, you wanted to ask whether the browser could synthesize a cors response and to ask whether the browser is capable of consistently identifying individual local devices
josh: can the browser synthesize a CORS response?
robin: presumably, what the browser is already doing is writing to the same whitelist that CORS is already using.
rich: robin's correct.
josh: should be spelled out in the spec.
robin: so long as we're confident it's the same processing internally in the browser to allow for cross-domain requests, then that's good.
josh: is the browser capable of consistently identifying individual local devices?
rich: that's a good question and a possible limit of the discovery protocol. A problem with zeroconf.
... Other protocols provide a unique identifier.
josh: can things bump of? Imagine someone knocks off my Wifi network and replace my stereo system with his.
robin: I guess the question is what happens if you trust something in the public network and it screws things over?
rich: we're working with the issues of UPnP.
<richt> robin: :)
josh: ok, too early probably to worry about that. We'll get to it.
... Last point: isn't UPnP dangerous?
robin: yes, if you have a UPnP controlled robot, then you can have it kill yourself.
josh: are there any deployed devices which have a delete button that doesn't require authentication?
rich: as part of my research, I'd say no.
<Cathy> UPnP has an optional device protection service (http://upnp.org/specs/gw/deviceprotection1/)
<richt> bottom line is UPnP is inherently insecure, hence the need for a security UI before connecting.
josh: my concern is "delete". Something I can't undelete.
<richt> actually any local networked services COULD be designed to be insecure. It's on a case-by-case basis.
robin: should this work with Web Workers?
rich: we need a user interface right now.
... I'd like it to work with workers.
robin: if you manage the connection in the main thread, then it could pass on to workers, right?
<richt> I like that approach Robin for getting this to work in Workers
robin: is the endpoint information something you can pass on to something else? Is it clonable?
josh: can it be guessed as well?
<richt> i.e. the synthesized CORS white-listing could be made to apply to both the main context and any SAME-ORIGIN web workers that hang off that context
[discussion about various intra-vein injections scenarios]
robin: any other technical questions?
... is the model extensible to other mechanisms? I'd guess yes.
rich: to be handled on a case by case basis. We took the two most obvious choices here.
... Back to Web Introducer, I considered but did not include here the possibility to register a service.
... Similar to introducer, but a little bit different.
robin: do you think you could expand on it in an email?
rich: sure, I don't think it should be put in the spec immediately.
josh: one word on caution of repeated authorization. I don't want an API to register and to unregister.
robin: in terms of next steps, do you want to check this in group's repository?
<Josh_Soref> richt, for the spec.... "[Supplemental, NoInterfaceObject] " the "Supplemental" bit is obsolete (and absent from the current WebIDL spec)
<richt> fwiw, there are similarities between the intended user experience between HTML5's registerProtocolHandler and this Service Discovery API.
rich: I'm going to be away, and would prefer to let people discuss this on the mailing list and will be able to join those discussions after August 12th when I'm back
robin: ok, thanks a lot rich, very good first stab at the problem.
rich: thanks. I look forward to seeing other proposals.
robin: any discussion on this with other browser vendors?
rich: very briefly.
... It fits browser vendor models as well as other models.
... As I said, I'd like to isolate some work in DAP so that people can join.
robin: going back to that, email tagging is efficient isolation for now?
rich: yes, I think so.
... Also a few people are allergic to meetings.
<robin> ACTION: Robin to create a wiki page with the list of tags [recorded in http://www.w3.org/2011/07/20-dap-minutes.html#action10]
<trackbot> Created ACTION-440 - Create a wiki page with the list of tags [on Robin Berjon - due 2011-07-27].
<Josh_Soref> Is it possible for the lists to bounce untagged messages with a list of possible (used) tags?
robin: ok. Maybe we should have a wiki page that lists tags.
[re: bouncing] it's not!
fjh: wondering if we could spend some time on new items in the charter.
<robin> http://www.w3.org/2011/07/DeviceAPICharter
fjh: Calendar, Contacts, Capture, Messaging, Network, we've discussed them already
<robin> http://berjon.com/blog/2011/06/integration-menu.html
fjh: vibration? System beeps? Application menus?
... Next step on vibration?
josh: for beep, just play an audio file, or ask people to define standard beep.
... I think the audio tag is sufficient.
bryan: Vibration and beeps come from BONDI. The idea was that there was no way to do that.
josh: [mentioning problems with vibration]
lgombos: it could be CSS actually.
josh: good point.
fjh: what if I want my IM app to give me a vibration upon notifications?
lgombos: handled by notifications.
robin: vibrate is simple to implement.
josh: yes but I don't want to deal with permissions for this.
robin: same as with audio. No permission with audio.
fjh: agreed that vibration we may keep. Kind of agreed beep is not needed.
... question is who's going to make a proposal on these specs?
robin: looking at feedback on beep. Some support from Cécile but use cases handled by notifications.
bryan: can you control the audio tag through script?
all: yes.
bryan: so you could use it to play a beep?
josh: yes.
robin: the only question was whether there was value in having a magic URL that points to the system beep.
RESOLUTION: drop the API to manage systems beeps
<robin> http://paulrouget.com/e/nativecontrols/
robin: for application menus, [showing Paul's demo]
josh: many browser are moving to real full screen, removing the menubar.
robin: that's a user interface issue. It could be a ribbon if you want a ribbon.
... There was a proposal that almost got sent to this working group that abstracts away the menus on various platforms. It could be a button, a top bar, a ribbon, something else.
<robin> ***timecheck***
francois: how much is already covered through a declarative approach.
robin: most of it, but there are issues with e.g. using rel. See my blog.
<robin> recess