See also: IRC log
<trackbot> Date: 23 November 2011
<scribe> Scribe: Josh_Soref
<darobin> 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> https://www.w3.org/2002/09/wbs/43696/mar2012-f2f/
darobin: we need to remember that the F2F dates are being selected
<dom> https://www.w3.org/2002/09/wbs/43696/mar2012-f2f/results
darobin: 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
<darobin> 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
<darobin> http://lists.w3.org/Archives/Public/public-device-apis/2011Nov/0204.html
darobin: I know they were sent out after the Agenda, any objections?
[ none ]
RESOLUTION: Minutes from last week are approved
<darobin> 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
<darobin> Josh_Soref: my plan is to look at moving Contacts and potentially Calendar towards intents model
<darobin> ... I might try a hypothetical thermometer API
<darobin> ... Contacts is mostly lookup
<darobin> ... 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
<darobin> Josh_Soref: would look at write and read as separate actions
<darobin> ... sort of thinking of it as look up contact in one action, then range action, then way to write/modify
<darobin> ... on either given contact or the list
<darobin> darobin: different actions ok, but probably same service
darobin: finding the limits of
Intents early is important
... so using more complicated UCs early to shake out the kinks
is important
<darobin> Josh_Soref: two parts to read-only data sources
<darobin> ... one is to throw an exception, the other is to have a separte API for writing
<darobin> ... exception APIs are disastrous: untested, unexpected unhandled
<darobin> [+1 to that]
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/thread.html
<darobin> Josh_Soref: dropping some pointers
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0011.html
<darobin> Josh_Soref: I've posted five parts of discussion on intents
<darobin> ... this is in part 3 about USB hubs
<darobin> ... with USB, devices will often have multiple profiles
<darobin> ... makes sense to be able to ask for an input device (keyboard), then ask for mouse, but UA can suggest existing one
<darobin> ... 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
<darobin> Josh_Soref: I went to Moz's WebAPI meeting yesterday
<darobin> ... poked them to look at contacts via intents
<darobin> ... WebAPI meeting is mostly about B2G more than W3
<darobin> ... goal is to ship by end of year
<darobin> ... did try to convince them to give feedback on intents, both on contacts and similar things
<darobin> ... 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
<Zakim> Josh_Soref, you wanted to comment on "native apps needing storage apis"
darobin: jcantera, since you have ideas and are using it, it's important for you to send your feedback there
<darobin> Josh_Soref: contacts native store is basically IDB, they don't need an API, the API is the IDB API
<darobin> ... then offer services to expose APIs atop that, for search, lookup, etc.
<darobin> ... tried to express that but seem to have failed
<darobin> 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
s/XXX/Travis/
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 ]
<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].
RESOLUTION: Move Battery API to LC
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
[ darobin explains his 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
<dom> (not sure about enforcing, but reminding at least?)
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0028.html
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> Josh_Soref, you wanted to object
<darobin> Josh_Soref: Sensors... suggestion of having an API for local sensors
<darobin> ... shouldn't be a difference between local/remote, should be hidden, not exposed to the Web
<darobin> ... no fingerprinting
<darobin> darobin: send it to jcantera's big pile of feedback
<darobin> jcantera: not only local sensors
<darobin> ... one of the methods, list(), only lists local sensors
<darobin> ... but it can be the same for remote
<darobin> ... it's a common interface
<darobin> ... one I have a sensor, get connection, data
darobin: this discussion should be captured in mail
<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
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/net/ent/ Succeeded: s/on is/one is/ Succeeded: s/Robin:/darobin:/ Succeeded: s/is/is in/ Succeeded: s/tasks/work/ Succeeded: s/Zakim: mute me// Succeeded: s/XXX/Travis/ FAILED: s/XXX/Travis/ Succeeded: s/Sun/Dzung/ Succeeded: s/+1/Josh_Soref: +1/ Succeeded: s/there's a YYY of/three weeks is/ Found Scribe: Josh_Soref Inferring ScribeNick: Josh_Soref Present: Deepanshu_Gautam Cathy_Chan Anssi_Kostiainen Kihong_Kwon Clarke_Stevens Josh_Soref Sakari_Poussa jcantera Laszlo_Gombos Travis_Leithead Niklas_Widell Regrets: Frederick_Hirsch Found Date: 23 Nov 2011 Guessing minutes URL: http://www.w3.org/2011/11/23-dap-minutes.html People with action items: josh robin[End of scribe.perl diagnostic output]