See also: IRC log
<trackbot> Date: 13 January 2010
<Dzung_Tran> Regrets, I can only be on for 40mins today.
<scribe> ScribeNick: paddy
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/att-0036/minutes-2010-01-06.html
RESOLUTION: minutes from 6 January are approved
fjh: any editors got any updates?
fjh: sent message to TAG as discussed
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0041.html
fjh: TAG acknowledged it and some discussion on list
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0067.html
<dom> Noah's response suggesting defining extensibility points for privacy
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0086.html (
fjh: Noah suggested using "extensibility point" for privacy
... could allow different means of passing privacy information as a general direction
... anyone any thoughts on this?
... Next step is to get into more detail, define use cases etc
... will leave this discussion to list
<fjh> Virtual web services
fjh: Other topic is virtual web services and there has been some discussion of this on list
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0061.html
fjh: I thought the approach suggesting using OAuth or other web-based authentication mechanisms
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0068.html
darobin: I thought OAuth was mentioned as something used on web generally, not necessarily solution for local case
... I don't think Mark was proposing this for the local case
<dom> John Kemp's early work on JavaScript using HTTP-like APIs
fjh: richt asked whether or not it is necessary to actually run a web server
... I think the answer was no, there are alternative implementations
... I don't have a clear picture of what's being proposed
... darobin do you have a better understanding?
darobin: I think the idea was to provide the same functionality as a normal API but exposed via XHR or similar
... like using a RESTful service, except that it's local
... happy to take on an action to flesh out what Mark said so it can be discussed in more detail
fjh: wanted to be explicit that it is different from defining a JS API
<darobin> ACTION: Robin to flesh out Mark's device as local web service proposal, using a Geo-based example [recorded in http://www.w3.org/2010/01/13-dap-minutes.html#action01]
<trackbot> Created ACTION-81 - Flesh out Mark's device as local web service proposal, using a Geo-based example [on Robin Berjon - due 2010-01-20].
fjh: I don't think it removes the requirement to define a policy framework (question)
... want to be clear on how much we are proposing changing what is already being discussed
<dom> [any objection to me raising an issue to match that discussion?]
darobin: will try to address as much as possible by fleshing out an example
fjh: any further coomments on this?
suresh: my initial reaction is that there are various things to discuss such as what does it mean to the approach we took so far
... is it truly that all the functionality we are interested in can be abstracted as a web service
... does it have an implication on how a Web Runtime is designed to operate?
... I think we need to understand the implications in a lot more depth before we can know how to take it forward
... if we are in a situation in which this model only addresses a subset of APIs in our charter, then will we end up with multiple approaches?
... I think we have to be very careful
<Zakim> dom, you wanted to suggest creating an issue and to note that Firefox's geolocation API implementation is backed by a... Web service (last I checked)
fjh: agree
dom: we should definitely create an issue to document the outcome of the discussion
<darobin> ISSUE: Investigation around Virtual Web Devices
<trackbot> Created ISSUE-66 - Investigation around Virtual Web Devices ; please complete additional details at http://www.w3.org/2009/dap/track/issues/66/edit .
dom: second point is that from memory the Firefox implementation of geolocation is based on a web service
... that's interesting in relation to this proposal
<richt> for the future I think web services = RESTful web apis
dom: ie it is a RESTful server (internally making GET requests and getting geolocation data back)
darobin: entered action and issue already
<Zakim> Frederick_Hirsch, you wanted to ask about timeline
fjh: what is the timeline for this analysis?
we want to do this issue investigation but don't want to stall existing work
scribe: so what is our timeline on this?
darobin: share concern, so the intent is that this investigation will take 1-2 weeks
... a few days to write up, 10 days or so discussion
... at that point at least we can decide whether or not it merits deeper investigation
<richt> to record my view, I think XHR is one implementation option for the current JS API but that does not disallow other methods of implementation
fjh: anything else to discuss on policy?
<marcin> NAP: http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0092.html
darobin: first item is whether or not we agree to publish contacts as FPWD
... no objections to CFP last week
<dom> CfC for publishing contacts as FPWD
darobin: so are there any objections here?
RESOLUTION: publish contacts as FPWD
richt: although no objections, there are some updates pending
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan0083.html
richt: do we publish as-is, or fix editorial issues first?
darobin: aren't they just minor?
richt: mostly minor
<Zakim> richt, you wanted to comment on outstanding editorial updates
darobin: why not fix minor issues first and then publish in next few days
fjh: was wondering about status of editorial comments, we should do the non-controversial ones
richt: edits in progress but not uploaded yet
... attribute naming etc can be worked on after FPWD
dom: should I be waiting for signal from richt to transition to FPWD?
<fhirsch> Publications only happen on Tuesdays and Thursdays, correct
richt: I will send update over next few days, and then it will transition to FPWD
don: I don't think there is any problem, no need to wait for next week's call
... but when do I know when the doc is ready?
<dom> ACTION: Dom to request transition of Contacts API as First Public Working Draft when pinged by Robin [recorded in http://www.w3.org/2010/01/13-dap-minutes.html#action02]
<trackbot> Created ACTION-82 - Request transition of Contacts API as First Public Working Draft when pinged by Robin [on Dominique Hazaël-Massieux - due 2010-01-20].
darobin: I will work with richt on ReSpec issues etc and will ping dom when done
<darobin> ACTION: Robin to ping Dom when Contacts FPWD is ready [recorded in http://www.w3.org/2010/01/13-dap-minutes.html#action03]
<trackbot> Created ACTION-83 - Ping Dom when Contacts FPWD is ready [on Robin Berjon - due 2010-01-20].
darobin: next topic is encouraging people to discuss capture API
<darobin> -< http://www.w3.org/mid/6B36E0FB-64A7-4E81-8639-67DB7FCDD7E3@robineko.com
<fhirsch> action-74?
<trackbot> ACTION-74 -- Robin Berjon to send an email to list summarising the options for <input> or not in Capture -- due 2009-12-16 -- CLOSED
<trackbot> http://www.w3.org/2009/dap/track/actions/74
darobin: to summarise, there has been a debate about using <input>, new API, <device> proposal etc
<Dzung_Tran> Should we keep the capture API simple for version 1.0 or extended to cover some advanced use cases
darobin: so a bit of a topic that's been all over the place
... so have come up with a rough proposal for 3 docs:
... 1) simple capture, not embedded
... 2) embeded viewfinder use case
... 3) streaming use case
... encourage people to jump into the thread and comment
... are there any comments now?
dom: I guess this proposal is that current proposal for capture is moot?
darobin: not completely, but it would need to be changed a lot?
dom: where would it fit in your 3 docs?
darobin: probably in the second doc, some aspects would be relevant such as start, stop etc, except architected differently
... next topic is "where does it all hang off of?"
... most list discussion was in favour of option (1)
... to clarify, this was the one with navigator.device.<api>.<method>
... people found it clearer, more extensible, less conflict with other existing properties of navigator
<AnssiK> I'm questioning whether device is something we're happy with, instead of service or something else
darobin: any objections to (1)?
richt: agree with (1)
... but proposed using a name different from "device"
... would prefer to rename to something more generic
... sent email to the list to that effect
<dom> ISSUE-44?
<trackbot> ISSUE-44 -- What do APIs hang off of? -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/44
<Suresh> Naming discussion is not easy:-)
darobin: saw email, wary of getting into unwelcome discussion of irrelevant and arbitrary issues
... we can split into two separate decisions
... 1) do we resolve to go with (1), irrespective of the name
<marcin> FWIF: navigator.service.* could handle device and network APIs
darobin: 2) what the property name is
<dom> window.navigator.universe-and-everything
<drogersuk> +1 on option 1
<Suresh> deviceService?
darobin: does anyone object to resolution to go with (1)?
<drogersuk> (assuming option 1 was option 1 from the email)
RESOLUTION: to go with option (1) for "where does it all hang off of?" but without a decision yet on the specific property name
<darobin> 1. Service object, simple method, inside device e.g. navigator.device.dahut.graze()
darobin: will raise an issue for naming of "device" part or do people not want to get into discussion?
marcin: need a resolution as much as possible
<AnssiK> I'd prefer a short and simple name, thus prefer e.g. service over deviceService
marcin: agreement on something is more important on what the actual name uis
<richt> RE: naming, my proposal (still option 1) is: navigator.service.dahut.graze()
darobin: will raise an issue that can be resolved next week
... ok?
<darobin> ISSUE: in navigator.device, should "device" be "service" or something else?
<trackbot> Created ISSUE-67 - In navigator.device, should "device" be "service" or something else? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/67/edit .
darobin: next topic is Max' action-80 on sys info but lets defer since Max is not here
<dom> close ISSUE-44
<trackbot> ISSUE-44 What do APIs hang off of? closed
darobin: so is there anything else anyone wishes to discuss?
<richt> thanks, bye
darobin: ajourned
<marcin> thanks & bye
<nwidell> quit
<fhirsch> y