W3C
Device APIs and Policy Working Group Teleconference
20 Jul 2011
Agenda
See also: IRC log
Attendees
Present
Cathy_Chan, Cecile_Marc, Christophe_Eyrignoux,
Daniel_Appelquist_(Lurking), Francois_Daoust, Frederick_Hirsch,
Ingmar_Kliche, Johnson_Wang, Josh_Soref, Kihong_Kwon, Kyung-Tak_Lee,
Orange, Rich_Tibbett, Robin_Berjon, Soonbo_Han, Sullivan_Bryan,
SungOk_You, Wang_Johnson, Wonsuk_Lee, ernesto_jimenez
Regrets
Chair
Frederick, Robin
Scribe
ernesto_jimenez, ingmar, cmarc, francois
Contents
* Topics <#agenda>
1. Administrative <#item01>
2. Testing <#item02>
3. Messaging API <#item03>
4. Media capture <#item04>
5. Permissions API <#item05>
6. network information <#item06>
7. Web and TV <#item07>
8. Discovery <#item08>
9. Charter deliverables review <#item09>
* Summary of Action Items <#ActionSummary>
------------------------------------------------------------------------
Date: 20 July 2011
trackbot, start telecon
Meeting: Device APIs and Policy Working Group Teleconference
Date: 20 July 2011
Chair: Robin_Berjon, Frederick_Hirsch
Agenda:
http://www.w3.org/2009/dap/wiki/F2F_Agenda_19,_20,_21_July_2011,_Paris
ScribeNick: ingmar
Administrative
scribe: ernesto_jimenez
scribenick: ernesto_jimenez
Testing
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
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
Draft charter of the Browser Testing and Tools WG (not yet
under review): http://www.w3.org/2011/08/browser-testing-charter.html
public-test-infra
francois: we have a public mailing list called public-test-infra
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?
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
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?
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
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?
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
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
http://w3c-test.org/dap/contacts/tests/
hg clone https://dvcs.w3.org/hg/dap
robin: is introducing the contacts test suite
http://w3c-test.org/dap/contacts/tests/test-suite.xml
http://dev.w3.org/2006/waf/widgets-api/imp-report/
robin: asking if anybody is interested in developing tests in the WG
http://dev.w3.org/2009/dap/messaging/
Messaging API
robin: introducing the messaging API
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
.addAttachments()
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)
*ACTION:* Robin to review Messaging for publication [recorded in
http://www.w3.org/2011/07/20-dap-minutes.html#action01]
Created ACTION-431 - Review Messaging for publication [on
Robin Berjon - due 2011-07-27].
scribe: ingmar
scribenick: ingmar
Media capture
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
http://dev.w3.org/2009/dap/camera/Overview-API
robin: current Media Capture API could be developed further towards
camera control (flash etc)
http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferencing-and-peer-to-peer-communication.html
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
[probably worth dropping the note in the introduction that
says "The Working Group is investigating the opportunity to specify
streaming access via the proposed element."]
issue: HTML Media Capture doesn't make sense if accept=image and
capture=microphone
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 .
issue: Should HTML Media Capture have options for front/user
camera as in getUserMedia
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 .
*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]
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
Permissions API
http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
lgombos__: this spec is used by the WebNotification spec
permissions feedback -
http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0042.html
http://berjon.com/blog/2011/06/numerical-constants-must-die.html
(webapps and html-wg are moving to numerical constants)
RESOLUTION: Switch to string constants
... 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
discussion on whether this functionality be available from workers
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"
*ACTION:* Laszlo to reply to Anne about his Permissions
questions [recorded in
http://www.w3.org/2011/07/20-dap-minutes.html#action03]
Created ACTION-433 - Reply to Anne about his Permissions
questions [on Laszlo Gombos - due 2011-07-27].
permissionLevel would be better as permissionLevelFor
robin suggests permissionLevel would be better as
permissionFor
http://www.w3.org/TR/api-perms/
robin: we leave the names as is
http://wiki.whatwg.org/wiki/RelExtensions
[ 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?
http://www.w3.org/2005/04/xpointer-schemes/
*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]
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?
[ 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
*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]
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].
action-435?
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
http://www.w3.org/2009/dap/track/actions/435
We probably want a testable example permission which can be
used for testing the specification
*ACTION:* Wonsuk to provide an example for Permissions [recorded
in http://www.w3.org/2011/07/20-dap-minutes.html#action06]
Created ACTION-436 - Provide an example for Permissions [on
WonSuk Lee - due 2011-07-27].
scribe: cmarc
ScribeNick: cmarc
could someone prod me when the agenda moves to Web & TV? ...
... 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.
network information
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?
[
http://developer.android.com/reference/android/net/ConnectivityManager.html
]
bryan: mobile or wifi should be sufficient
http://davidbcalhoun.com/2010/using-navigator-connection-android
[
http://developer.android.com/reference/android/net/NetworkInfo.html ]
josh: care about roaming
if the apps can know your cost ..
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
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
http://www.mobilexweb.com/blog/android-froyo-html5-accelerometer-flash-player
robin: should we talk to google people about that
*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]
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
*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]
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?
Feedback from others has been about wanting to get
information from medical sensors
Our response to them was to try using a local websocket
source to translate the information for use by web apps
It might make sense to have a NOTE suggesting something
like that to people interested in exposing sensors
*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]
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
[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
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)
Web and TV
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
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
--- break ---
scribe: francois
Discovery
http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0073.html
rich: I'll present an introduction to how I see things here.
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.
[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.
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?
[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.
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?
[ 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.
ack
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.
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.
UPnP has an optional device protection service
(http://upnp.org/specs/gw/deviceprotection1/)
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.
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?
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?
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?
richt, for the spec.... "[Supplemental, NoInterfaceObject]
" the "Supplemental" bit is obsolete (and absent from the current WebIDL
spec)
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.
*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]
Created ACTION-440 - Create a wiki page with the list of tags
[on Robin Berjon - due 2011-07-27].
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.
http://www.w3.org/2011/07/DeviceAPICharter
Charter deliverables review
fjh: Calendar, Contacts, Capture, Messaging, Network, we've discussed
them already
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*
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.
***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.
recess
Summary of Action Items
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *ACTION:* Laszlo to reply to Anne about his Permissions
questions [recorded in
http://www.w3.org/2011/07/20-dap-minutes.html#action03]
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *ACTION:* Robin to review Messaging for publication [recorded in
http://www.w3.org/2011/07/20-dap-minutes.html#action01]
*[NEW]* *ACTION:* Wonsuk to provide an example for Permissions [recorded
in http://www.w3.org/2011/07/20-dap-minutes.html#action06]
[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
version
1.135 (CVS log )
$Date: 2009-03-02 03:52:20 $