See also: IRC log
<trackbot> Date: 20 January 2010
<darobin> we should install a rule that whoever joins last gets to scribe
<arve> we should get someone to donate voice recognition
<scribe> ScribeNick: AnssiK
<fhirsch> Prague F2F logistics sent to list
darobin: no specifics on the Prague f2f logistics, see the DAP page for more info, or ask Robin
RESOLUTION: minutes from 13 Jan approved
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/att-0105/minutes-2010-01-13.html
fh: Robin has sent a nice summary of REST approach to the ML
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0164.html
<fjh> my comments - http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0166.html
<dom> ISSUE-66?
<trackbot> ISSUE-66 -- Investigation around Virtual Web Devices / REST-ful oriented APIs -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/issues/66
<dom> ACTION-81?
<trackbot> ACTION-81 -- Robin Berjon to flesh out Mark's device as local web service proposal, using a Geo-based example -- due 2010-01-20 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/81
darobin: Robin's doc discusses the advantages and issues with exposing local data services as REST services instead as of APIs.
... an example use case for REST API discussed: contacts can be exposed by services such as FB etc.
... Robin is asking for feedback on the ML
fh: do we need a specific JS library to hide the bare-metal XHR?
darobin: jQuery is just an example that could be used
... also noted jQuery is an open source library
fh: a special protocol is needed, a concern?
darobin: push use cases are a bit problematic in REST API
<arve> (for a dumb question)
fh: what were Steven's and John Kemp's proposals referred on the doc?
darobin: Steven's proposal not documented, was f2f
<fhirsch> suggestion from stephen to provide generic database like interface to contacts etc
<dom> [that's one of the things Robin highlights in the document http://dev.w3.org/2009/dap/docs/virtual-ws.html#which-uri-to-expose]
<dom> Arve: given the struggle we have been going through for registering the widget: URI scheme, it looks like defining a new scheme for something that would use as if it was HTTP is likely to be problematic
<arve> My question is one : If we are doing something _nearly_ like HTTP, why shouldn't we just use HTTP in the first place, and require local web servers?
<arve> and wouldn't that actually require us to specify these APIs in a non-rest way anyhow
<fhirsch> I think arve is saying we need javascript APIs as a base for an HTTP REST interface anyway
<Zakim> richt, you wanted to discuss how the response data is defined (in WebIDL?)
<arve> fhirsch, +1
<fjh> proposed action - arve to write up example of need for javascript API even with HTTP REST interface
<dom> +1 on proposed ACTION:)
<arve> action accepted
<trackbot> Sorry, bad ACTION syntax
<darobin> ACTION: arve to detail his view on double-API specification for LREST [recorded in http://www.w3.org/2010/01/20-dap-minutes.html#action01]
<trackbot> Created ACTION-84 - Detail his view on double-API specification for LREST [on Arve Bersvendsen - due 2010-01-27].
richt: response data format must be well-formatted
... could be JSON or XML, for example
darobin: let's focus on a one data exchance format
<Zakim> richt, you wanted to discuss how the response data is defined (in WebIDL?) ...in not too much detail :-)
fh: we'll need to walk though the security considerations
... asking if BONDI has some related input
... does OAuth solve all out problems?
paddy: the topic was discussed in BONDI in its early stage
... and I can summarize the issues
<darobin> ACTION paddy to provide his thoughts on LREST based on experience from BONDI's earlier discussions on the same
<trackbot> Sorry, amibiguous username (more than one match) - paddy
<trackbot> Try using a different identifier, such as family name or username (eg. pbyers, pbyers2)
<darobin> ACTION pbyers2 to provide his thoughts on LREST based on experience from BONDI's earlier discussions on the same
<trackbot> Created ACTION-85 - Provide his thoughts on LREST based on experience from BONDI's earlier discussions on the same [on Paddy Byers - due 2010-01-27].
<fjh> ilkka notes benefit of remote access to apis via rest approach, but without remote access will require additional implementation work vs javascript approach
<fjh> need to distinguish remote access to device versus device accessing local or remote services from device
<fjh> or do we
darobin: the thinking is that the same REST API could be used to access both remote and local services
richt: the current JS API approach enables fallback to other conforming implementation, e.g. if the local fails fall back to cloud
darobin: let's follow-up on the ML
<Suresh> sorry to be so late!
darobin: contacts FPWD is in the pipeline i.e. out tomorrow
<dom> ACTION-82?
<trackbot> ACTION-82 -- Dominique Hazaël-Massieux to request transition of Contacts API as First Public Working Draft when pinged by Robin -- due 2010-01-21 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/82
darobin: Where does it all hang off of decision
... and the winner is: service (least hated option)
<dom> ISSUE-67?
<trackbot> ISSUE-67 -- In navigator.device, should "device" be "service" or something else? -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/issues/67
<Suresh> navigator.dap.*?
<tlr> I think it needs to be service.dap
dom: happy with the "service"
<darobin> PROPOSED RESOLUTION: go ahead with "service", document it in Core Devices, and mark it as pending feedback from implementors
<Suresh> q
<arve> -1
<richt> we can always change later based on implementation feedback
<marcin> when is it to made final? at REC level of Core DEvices?
<marcin> fjh, navigator.service.*
Suresh: we have to describe if the implementation is local or remote
<marcin> darobin, thanks
<darobin> ACTION Robin to update Core Devices
<trackbot> Created ACTION-86 - Update Core Devices [on Robin Berjon - due 2010-01-27].
<richt> 'service' means 'requires interaction with an external entity - device/web or otherwise'.
<Zakim> arve, you wanted to explain his objection
Suresh: just to make sure people do not misinterpret the term "service"
arve: "service" means different things to different people, in the Web context it has always referred to a web service -- causes confusion
<maxf> brb
<tlr> ugh
arve: Opera Unite APIs also have a notion of a service, which is a traditional web service
<fjh> arve argues that using service implies web services approach, not necessarily agreed
<Suresh> or, I think something neutral would be better e.g. "dap"
darobin: general conflict with service?
arve: does not want to call File I/O or Geolocation a "service"
<darobin> PROPOSED RESOLUTION: call it "monkey"
<marcin> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0154.html
tlr: if we continue to have strong feelings on the issue, perhaps we do not need a common ns at all
<blassey> navigator++
<Suresh> I don't think we should be going back
<arve> navigator++
<maxf> navigator++
<darobin> PROPOSED RESOLUTION: just put stuff on navigator, if it breaks the web we'll cross that bridge then
<tlr> do we have any such objects?
http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0150.html
<richt> Consider this on an API by API basis? e.g. Sys info would probably benefit from navigator.device (it is device only at all times) but contacts and calendar benefits from navigator.service or navigator.resource (it is abstract and can be linked to any external contact providing entity, web or otherwise).
from John Kemp's mail: "My reasoning for having a group name (I prefer 'service') might be that if we were to create constants that might be relevant to _all_ of the APIs then rather than place them in each individual API object, we could put them into the "global" object. Do we have anything that looks like it might fit?"
<darobin> PROPOSED RESOLUTION: decide nothing, leave each API duke it out on its own
fjh: security and privacy mechanisms may benefit from a common ns, is this a consideration?
<paddy> +1 for formal vote service vs device vs dap
Suresh: we shouldn't go back to navigator.foo
darobin: we may need to vote
<darobin> PROPOSED RESOLUTION: decide nothing, leave each API duke it out on its own
<darobin> PROPOSED RESOLUTION: enforce nothing, leave each API duke it out on its own
<fjh> +1 to taking to the list
<darobin> PROPOSED RESOLUTION: leave each API duke it out on its own
Suresh: would like to come to an agreement on the call
<fjh> my +1 was to try to get to an agreement on common space on list
<Suresh> +1
<arve> +1
darobin: everyone happy with the proposed resolution?
<darobin> RESOLUTION: leave each API duke it out on its own
<Suresh> my +1 was the same as fredrick's +1 but no worries!
<dom> 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
<dom> (actually Dzung did comment)
ilkka: a reasonable proposal, what's the split across L1, L2, L3
<dom> (+1 on v1 being level 1 and level2)
<ilkka> +1
darobin: v1 could be L1 and L2
ilkka: supports
... can think how to turn this into a spec
<dom> (I would like to hear progress reports (or lack thereof) on Messaging and Calendar, if possible)
maxf: the spec exposes multiple devices for a given property
... e.g. for power, battery, AC
... the question is whether this level of detail is useful
... some people argued not good enough use cases to support such granularity
<maxf> http://dev.w3.org/2009/dap/system-info/properties-simplified.png
maxf: a simplified set of properties was suggested
... example: replaced n CPU loads with one, the same for power and others
<darobin> ACTION maxf to look at potential proc alignment (as a suggestion)
<trackbot> Created ACTION-87 - Look at potential proc alignment (as a suggestion) [on Max Froumentin - due 2010-01-27].
<Suresh> back on the call!
<nwidell> (need to leave the call in a two minutes) Messaging: Rough draft of SMS done (including comment on SMS URI).
darobin: any objections to publish FPWD?
maxf: can do the edits (simplification) in couple of days
<Zakim> richt, you wanted to talk about status update on Calendar API
richt: will do the edits by the end of this weeks
nwidell: a rough release of Messaging API perhaps out in the end of this week
darobin: Planning for the 25% point: where do we want to be by the F2F?
... should revisit the timelines on the DAP site
(none)
<darobin> thanks a lot AnssiK!
<darobin> as the first person to scribe twice you get extra beer
