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 it's 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 formalised 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: we have a public mailing list called 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
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?
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 organisations and companies
Youngsun: asks about TV testing?
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?
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> hg clone https://dvcs.w3.org/hg/dap
robin: is introducing the contacts test suite
robin: asking if anybody is interested in developing tests in the WG
robin: introducing the messaging API
robin: there was an issue where you could not know what protocol was available, so a new design was suggested
<robin> <a href='mailto:firstname.lastname@example.org'>
<robin> <a href='xmpp:email@example.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
topic "Media capture"
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: current Media Caputure 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
robin. the media capture api provides a few advantages over HTML media caputure, 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
... 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 dosn'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
lgombos__: this spec is used by the WebNotification spec
<lgombos__> permissions feedback - http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0042.html
<Josh_Soref> (webapps and html-wg are moving to numerical constants)
<robin> RESOLUTION: Switch to string constants
<robin> ... because existing implementatons 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 chnages 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: we leave the names as is
<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
... the only legacy spec seems to be geolocation
Josh_Soref: how about versioning?
<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].
<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
<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: has feedback from ingmar
the problem is the cost information
<richt> actually, I will dial in and listen now. Could someone open the bridge?
status in wac or gsma
look in android 2 types
wifi and ..
is it useful to have detail 2g, 3G
mobile or wifi should be sufficient (bryan)
<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
there is an operator in africa who offer the same price for 5 countries
section 4, multiple online event
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 relevent 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
bb as well
josh: we should find out what is used
google api is not documented
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
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 acceleromter 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]
there was no deployed implementation in bondi
implemented probably but not deployed ....
basically, if you don't trust websites...
overall synsinfo status spec is not moving
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
François : it is an interest group, don't develop standards
scribe: [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
two active TF: home networking task force
and mediapipeline TF
robin: hbbtv? involved
national, regional organization involved
many companies, broadcasters, etc..
François: some are invited to join dap
scribe: ... 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..
françois: there is not point to have a web and TV working group.
scribe: ... 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.
scribe: 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 is this does not work out... we will have to find something else
<robin> --- break ---
<francois> scribe: francois
rich: I'll present an introduction to how I see things here.
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.
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
... 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.
fjh: so the developer needs to have an understanding of what's going on underneath.
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
... 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
Cathy: do you foresee if you just do all the UPnP discovery in the background?
[ 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 notifications, then lots of requests will be generated.
rich: yes, we'll handle that if needed
[ more discussion on "background" concerns. Please make points scribe missed on IRC ]
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?
<Cathy> s/sending notifications/sending periodic notifications/
rich: yes, that's an interesting angle.
<Cathy> s/lots of requests will be generated/lots of messages will need to be processed/
rich: 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 unsecure.
... [Other solutions mentioned such as the one used in Google TV]
... In short, changes are required to CORS.
<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
<Cathy> s/[ more discussion on "background" concerns. Please make points scribe missed on IRC ]/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./
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
... 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 authentification?
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
... 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 applies to both the main context and any SAME-ORIGIN web workers that hang off that context
<richt> s/white-listing applies to both/white-listing could be made to apply to both/
[discussion about various intra-vein injections scenarios]
robin: any other technical
... 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 this slip a bit.
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.
<richt> s/to let this slip a bit./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> 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.
fjh: wondering if we could spend some time on new items in the charter.
fjh: Calendar, Contacts, Capture, Messaging, Network, we've done something
s/done something/discussed them already/
fjh: vibration? System beeps?
... 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?
bryan: so you could use it to play a beep?
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: 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..
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.
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/XXX1/ETSI/ Succeeded: s/brian/bryan/ Succeeded: s/spech/spec/ Succeeded: s/caputure/capture/ Succeeded: s/lazlo/lgombos__/ Succeeded: s/webnotification/permissions/ Succeeded: s/lgombos__/lgombos__: I/ Succeeded: s/metion/mention/ Succeeded: s/features/when distinct feature names might be needed/ Succeeded: s/inf out/find out/ Succeeded: s/mobile/mobile (and sadly even non-mobile)/ Succeeded: s/he/the/ Succeeded: s/klaas/Claes/ Succeeded: s/stag/tag/ Succeeded: s/oh god, we're talking about 'synergies'.// Succeeded: s/he home nework/the home network/ Succeeded: s/producing use cases and requirement/producing use cases and requirements/ Succeeded: s/why does this stupid bot tell me to go visit a link then flood the channel?// Succeeded: s/dap new charter/DAP's new [proposed] charter/ Succeeded: s/has to move to WG/are encouraged to move to WG .../ Succeeded: s/as the subject/... as the subject/ Succeeded: s/in this group/in this group;/ Succeeded: s/so that they/... so that they/ Succeeded: s/also on deliverables/also on deliverables./ Succeeded: s/TV is an important/... TV is an important/ Succeeded: s/web and TV working group/web and TV working group./ Succeeded: s/one topic discussed/... One topic discussed/ Succeeded: s/because TV is often the middle/... because TV is often the middle/ Succeeded: s/device discovery/... Device discovery/ Succeeded: s/(charter/... (charter/ Succeeded: s/approval-soon)/approval-soon)./ Succeeded: s/the home network TF/... The home network TF/ Succeeded: s/producing use cases and requirements/producing use cases and requirements./ Succeeded: s/DAP could use those use /... DAP could use those use / Succeeded: s/the participants of the TF are/... the participants of the TF are/ Succeeded: s/to contribute here in DAP/... to contribute here in DAP./ Succeeded: s/as the subject they are interested in/... as the subject they are interested in/ Succeeded: s/One topic discussed is device discovery/... One topic discussed is device discovery/ Succeeded: s/find out (sorry)// Succeeded: s/depployed/deployed/ Succeeded: s/was created following the workshop/[the wiki?] was created following the workshop/ Succeeded: s/[the wiki/... [the wiki/ Succeeded: s/following the workshop/following the workshop./ Succeeded: s/asyncrhonous/asynchronous/ FAILED: s/sending notifications/sending periodic notifications/ FAILED: s/lots of requests will be generated/lots of messages will need to be processed/ FAILED: s/[ more discussion on "background" concerns. Please make points scribe missed on IRC ]/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./ FAILED: s/white-listing applies to both/white-listing could be made to apply to both/ FAILED: s/to let this slip a bit./to let people discuss this on the mailing list and will be able to join those discussions after August 12th when I'm back/ FAILED: s/done something/discussed them already/ Succeeded: s/.././ Found ScribeNick: ingmar Found Scribe: ernesto_jimenez WARNING: No scribe lines found matching ScribeNick pattern: <ingmar> ... Found ScribeNick: ernesto_jimenez Found Scribe: ingmar Found ScribeNick: ingmar Found Scribe: cmarc Found ScribeNick: cmarc Found Scribe: francois Inferring ScribeNick: francois Scribes: ernesto_jimenez, ingmar, cmarc, francois ScribeNicks: ingmar, ernesto_jimenez, cmarc, francois Present: Cecile_Marc Kihong_Kwon Francois_Daoust Robin_Berjon Frederick_Hirsch Christophe_Eyrignoux SungOk_You Kyung-Tak_Lee ernesto_jimenez Johnson_Wang Sullivan_Bryan Wonsuk_Lee Ingmar_Kliche Soonbo_Han Daniel_Appelquist_(Lurking) Josh_Soref Wang_Johnson cecile_Marc Cathy_Chan Rich_Tibbett Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_19,_20,_21_July_2011,_Paris Found Date: 20 Jul 2011 Guessing minutes URL: http://www.w3.org/2011/07/20-dap-minutes.html People with action items: bryan dom ernesto josh laszlo robin wonsuk[End of scribe.perl diagnostic output]