See also: IRC log
<trackbot> Date: 23 November 2011
<scribe> Scribe: Josh_Soref
http://www.w3.org/mid/A5572620-7342-408E-B4E7-778B0E823919@berjon.com
darobin: it seems we don't have many people
... Josh_Soref, thank you for the scribing again
darobin: I know they were sent out after the Agenda, any objections?
[ none ]
RESOLUTION: Minutes from last week are approved
https://www.w3.org/2002/09/wbs/43696/mar2012-f2f/
https://www.w3.org/2002/09/wbs/43696/mar2012-f2f/results
darobin: we need to remember that the F2F dates are being selected
... please be sure you fill it out if you want to have a say about the date for the F2F
... it seems that the current winner is Mar 13
http://www.w3.org/TR/vibration/
darobin: The Vibration API has been published
... hopefully as it's a short spec we can move to LC very soon
http://lists.w3.org/Archives/Public/public-device-apis/2011Nov/0204.html
http://www.w3.org/mid/CAO800SxJtMp6+UyV4d1Z3CPE5VvL8CeOJd=pFEd6Ep8Dk5zLTQ@mail.gmail.com
darobin: It has now started, and there is a ML called public-web-intents
http://lists.w3.org/Archives/Public/public-web-intents/
darobin: one thing that would be useful is to look at the current APIs we have
... and see if we can work out whether they can be worked
... into using Intents
Josh_Soref: my plan is to look at moving Contacts and potentially Calendar towards intents model
... I might try a hypothetical thermometer API
... Contacts is mostly lookup
... Thermometer is more about pairing — different case, different way of working
<darobin> ACTION: Josh to investigate using intents for Contacts, perhaps Calendar and Thermometer [recorded in http://www.w3.org/2011/11/23-dap-minutes.html#action01]
<trackbot> Created ACTION-491 - Investigate using intents for Contacts, perhaps Calendar and Thermometer [on Josh Soref - due 2011-11-30].
<Zakim> darobin, you wanted to discuss writeback
darobin: you mentioned Contacts being a simple lookup
... you know that initially we also had a Contacts WriteBack
<Dzung_Tran> Should thermometer be part of sensors
darobin: i think it might be useful to look into Writing/Deleting in Intents as well
... that might surface more interesting limits on the model
<spoussa> +1 for contacts write and delete
Josh_Soref: would look at write and read as separate actions
... sort of thinking of it as look up contact in one action, then range action, then way to write/modify
... on either given contact or the list
darobin: different actions ok, but probably same service
... finding the limits of Intents early is important
... so using more complicated UCs early to shake out the kinks is important
Josh_Soref: two parts to read-only data sources
... one is to throw an exception, the other is to have a separte API for writing
... exception APIs are disastrous: untested, unexpected unhandled
<darobin> [+1 to that]
Josh_Soref: dropping some pointers
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/thread.html
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0011.html
Josh_Soref: I've posted five parts of discussion on intents
... this is in part 3 about USB hubs
... with USB, devices will often have multiple profiles
... makes sense to be able to ask for an input device (keyboard), then ask for mouse, but UA can suggest existing one
... so in contacts, you can say "already asked for lookup", upon write-back, UA says "hey, this service can do that too"
darobin: right, i see what you're getting to
<Dzung_Tran> Have the WebEvents WG looks into this for Joystick API
darobin: definitely if you could look into the UC, it'd be good
jcantera: I have comments on Web Intents in general
... since the TF is doing the Academic exercise that was done in the past
... the results have not been very good, creating things that implementers aren't very interested in
... I thought it was going to look at Google's input
... It would help if the Intents work would focus on already identified UCs
... And not look into things Implementers won't implement
darobin: the reason we're not looking at the Draft yet
... is that it hasn't been uploaded
... and we're working on Administration work
... once we have the Draft in hand, it will be easier to make comments on it
... [ The draft has support from One, One and a half implementers ]
... Once it's available, it's important to look at Intents and see if
... it addresses the UCs
... so other groups can know if it will work for them
... does that make sense?
jcantera: yes
... but if it diverges
... it may go slower than we expected
... if you have open/long discussions
... the initial `intent` is different
darobin: I invite you to take your concerns to the intents list
... i think you're on it
... i know you're working w/ the B2G people
... one thing that would be very valuable for the Intents TF
... would be for Mozilla to be more active
... I spoke to a number of Mozilla people @TPAC
... and I know they have reservations
... on Intents
... I know you're working closely with them, and I think it would help if you'd encourage them to share their feedback
jcantera: My concern is that DAP/Mozilla/Intents are going along different paths
... it isn't your fault if Mozilla doesn't provide input
darobin: I'm certainly hoping that the fact that Google is submitting their Draft to the TF
... and sharing their Draft
... and Chairing the TF
Josh_Soref: I went to Moz's WebAPI meeting yesterday
... poked them to look at contacts via intents
... WebAPI meeting is mostly about B2G more than W3
... goal is to ship by end of year
... did try to convince them to give feedback on intents, both on contacts and similar things
... we need to push them more
<darobin> ACTION: Robin to prod DavidA and Shane about feedback on Activities/Intents [recorded in http://www.w3.org/2011/11/23-dap-minutes.html#action02]
<trackbot> Created ACTION-492 - Prod DavidA and Shane about feedback on Activities/Intents [on Robin Berjon - due 2011-11-30].
jcantera: I was on yesterday's call too
... but I think we need the contacts application
... to have a native api
... for storing and retrieving
darobin: I'd like to avoid spending too much time on Intents since there is a TF for it
... rather than discussing it here where we don't have the key players
... it's important to discuss it in the TF
... jcantera, since you have ideas and are using it, it's important for you to send your feedback there
<Zakim> Josh_Soref, you wanted to comment on "native apps needing storage apis"
Josh_Soref: contacts native store is basically IDB, they don't need an API, the API is the IDB API
... then offer services to expose APIs atop that, for search, lookup, etc.
... tried to express that but seem to have failed
http://www.w3.org/mid/22C84B78-685C-4B6F-85E4-A12BC073D075@berjon.com
darobin: ... yay, another TF
... there's a Draft Charter that I put out a couple of weeks ago
... we need it to be accepted by both groups
... any objections?
... there hasn't been much discussion about it
<AnssiK> +1
darobin: there was a little feedback from Travis
Travis: I'm in favor
... have we had any feedback from WebRTC?
darobin: hearing no objection, and some support
... resolution for accepting it?
... the Mailing List isn't up yet
<Travis> Excellent.
darobin: it comes after the Charter is accepted
RESOLUTION: Accept Media Capture TF Charter
AnssiK: since CfC
... the spec got reviewed by the implementer
<AnssiK> http://www.w3.org/mid/DC3F966B-34F0-42E1-9DEF-0D3FA45DF8EC@nokia.com
AnssiK: we received feedback and spotted some bugs in the spec
... we've corrected them
... the spec should be finally aligned with the implementation
... so I think we're ready to move to LC
<AnssiK> +1
<lgombos> +1
<dom> +1
<spoussa> +1
darobin: Any objections to moving battery to LC?
[ None ]
RESOLUTION: Move Battery API to LC
<dom> Yay!
<darobin> ACTION: Robin to publish Battery API as LC, transition request it [recorded in http://www.w3.org/2011/11/23-dap-minutes.html#action03]
<trackbot> Created ACTION-493 - Publish Battery API as LC, transition request it [on Robin Berjon - due 2011-11-30].
darobin: there's been discussion on the list
jcantera: we've received many feedbacks
... both on the B2G list and also the DAP list
... there were some mistakes in the WebIDL syntax in the Spec
... which were pointed out on the B2G list
... there was feedback from Claes concerning the list of Find methods
... the idea is
... the group is exploring the idea of Intents as a way of doing Discovery
... one of the options is not to cover Discovery in the Sensor API
... or only have a list method to find a way to cover local sensors on the device
... I favor having a way to see local sensors
... and use Intents for sensor discovery
... there was also a discussion concerning Ranges
... and differing sensor data
... I think Dzung was involved in that
<jcantera> https://github.com/jmcanterafonseca/SensorGapPlugin
jcantera: I presented a sensor plugin @TPAC
... i think it's way to get more feedback from the developer community
... the next step with sensors is
... collecting/addressing the feedback we've received
... and then try to publish a WD on Sensors
... and get more feedback from W3 community in general
<Zakim> darobin, you wanted to talk about next steps: keep iterating since discussions are working out; bother with process stuff later
darobin: what i'm hearing/seeing in the discussions
... is there's a good level of interest
... and you have quite a lot of feedback to integrate
jcantera: yes, we need to do that in the next week
darobin: before we jump to publication, i think it would be good to integrate that feedback
... otherwise we'd publish a draft behind what we know in terms of feedback
... so next step is to update to incorporate your feedback
<darobin> oh oh
darobin: and then ping the list
... Thanks for coordinating the discussion over multiple lists
<Zakim> Josh_Soref, you wanted to object
Josh_Soref: Sensors... suggestion of having an API for local sensors
... shouldn't be a difference between local/remote, should be hidden, not exposed to the Web
... no fingerprinting
darobin: send it to jcantera's big pile of feedback
jcantera: not only local sensors
... one of the methods, list(), only lists local sensors
... but it can be the same for remote
... it's a common interface
... one I have a sensor, get connection, data
darobin: this discussion should be captured in mail
[ darobin explains his call-drop is due to poor provisioning ]
<AnssiK> should we try to enforce a ML netiquette on public-device-apis similar to http://www.w3.org/2008/webapps/wiki/WorkMode#Mail_List_Policy.2C_Usage.2C_Etiquette.2C_etc. or http://www.w3.org/mid/CAACrNNfYMJJpWQ1U=hAk62O+VDcwvPeSg7g6WgYzFuL38RrXNA@mail.gmail.com
AnssiK: I wonder if we should try to ensure proper etiquette on the ML
... I see that Josh_Soref raised this on the Web Intents ML
... should we raise this, things like "no top posting"
... we have new people
Josh_Soref: http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0028.html
<dom> (not sure about enforcing, but reminding at least?)
AnssiK: i'm asking the Chairs to remind people
darobin: I agree with dom, enforcing is hard
... but i'm happy to remind people
... and I can add a link to the wiki
AnssiK: right, Notify/Inform people
... it isn't documented in the DAP wiki
... WebApps has guidance
<darobin> ACTION: Robin to email the list about email etiquette and link from the wiki to WebApp's etiquette [recorded in http://www.w3.org/2011/11/23-dap-minutes.html#action04]
<trackbot> Created ACTION-494 - Email the list about email etiquette and link from the wiki to WebApp's etiquette [on Robin Berjon - due 2011-11-30].
AnssiK: and Josh_Soref posted his to the Intents ML
... ideally all groups would have the same netiquette for MLs
... it seems silly to have divergence
darobin: I agree with you on principle
... that said, it's likely there's a netiquette page *somewhere* on the w3c site
<dom> http://www.w3.org/Mail/ links to Mail Etiquette http://www.ietf.org/rfc/rfc1855.txt under "Policies"
darobin: I encourage you to raise your concern to the new Process group
... this is something that can be raised in Charters
<Zakim> dom, you wanted to mention staff contacts transition
dom: I will be transitioning out of DAP in the coming months
... dsr will be the staff contact in my stead
<darobin> RESOLUTION: Dom rocks!
dom: i will be taking over francois's responsibilities in WebRTC
... heads up that dsr is now in charge
... questions on the group should now be addressed to dsr
darobin: definitely a huge thanks to you dom, for the work you've done
<Travis> +1
Josh_Soref: +1
<Zakim> dom, you wanted to ask duration of battery lc
darobin: minimum is 3 weeks
... but i'm open to longer if needed
... any opinions
dom: three weeks is Dec 15
... 3 weeks might be short
darobin: i'm fine with making a LC that goes a bit into January
... it's not like transitioning right before Christmas does us much good
dom: let's go to Dec 16
darobin: oh you want the end of the week
... thank you very much
... see you next week