- From: Robin Berjon <robin@robineko.com>
- Date: Wed, 2 Dec 2009 17:07:30 +0100
- To: public-device-apis@w3.org
Hi all,
many thanks to Laura for these minutes!
Online:
http://www.w3.org/2009/12/02-dap-minutes.html
In text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Device APIs and Policy Working Group Teleconference
02 Dec 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0022.html
See also: [3]IRC log
[3] http://www.w3.org/2009/12/02-dap-irc
Attendees
Present
Dzung_Tran, Wonsuk_Lee, Robin_Berjon, Max_Froumentin,
Dominique_Hazael-Massieux, Ilkka_Oksanen, Laura_Arribas,
Paddy_Byers, Richard_Tibbett, Marco_Marengo, Marcin_Hanclik,
Anssi_Kostiainen, Ingmar_Kliche, Suresh, Chitturi
Regrets
Frederick
Chair
Robin Berjon
Scribe
Laura Arribas
Contents
* [4]Topics
1. [5]policy segment
2. [6]API segment
3. [7]Contacts
4. [8]Capture API
5. [9]core devices
* [10]Summary of Action Items
_________________________________________________________
<trackbot> Date: 02 December 2009
<ilkka> dom, very OK for me if you want to be Capture API editor
<dom> ilkka, thanks :)
<arve> Re camera/capture API
<arve> Is there any particularily good reason why we don't express
the audio/video data as URIs?
<dom> hmm… the stream of data is available behind a URI; providing
the data as a data: URI wouldn't work (think of a big video record)
<darobin> trackbot, start meeting
<trackbot> Meeting: Device APIs and Policy Working Group
Teleconference
<trackbot> Date: 02 December 2009
<ilkka> arve, do you mean viewfinder stream or images/videos the
user takes
<arve> dom, No, I'm not talking about addressing the stream
<arve> but the resource providing it
<arve> <video src="foo:video/camera/1/">
<arve> then the spec would be concerned with extracting stream data
from a well-defined resource
<dom> oh, you're talking about the viewfinder aspect; I think we're
considering it out of scope for v1 based on the recent discussions
<darobin> early talk seems indeed to consider putting the VF in
<video> out of scope for v1
<arve> No, I'm not talking about the viewfinder aspect
<arve> I'm talking about the capture aspect as well
<arve> darobin, the actual context is a comment from Hixie on
#whatwg
<arve> because he doesn't see the value of the proposal over <input
type="file">
<arve> dom, Would a strawman spec suffice?
<dom> absolutely
<darobin> arve, while RRSAgent is logging can you use , instead of :
to address people? otherwise it gets mixed up as someone being
minuted
<arve> darobin, sure
<darobin> thanks!
<darobin> arve, for the record, strawmen proposals are always
welcome on the list of course
<darobin> Laura_Arribas, you're at the top of the victims list,
ready to scribe?
yes
<darobin> excellent, thanks!
but not in the call yet
:)
<darobin> Scribe: Laura Arribas
<darobin> ScribeNick: Laura_Arribas
<Dzung_Tran> Can only be on Chat today, my VOIP is not working
<darobin> let's wait a minute or two
<darobin> arve, are you calling in?
<darobin> damn you Zakim!
<darobin> ok, let's get started
robin: any announcements?
<dom> [11]Tlr's invitation to public-web-security mailing list
[11] http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0018.html
robin: Thomas sent an e-mail about the web security mailing list
<darobin>
[12]http://www.w3.org/mid/6CA62A05-248C-43C8-91CB-BEA6B0FAF11B@nokia
.com
[12] http://www.w3.org/mid/6CA62A05-248C-43C8-91CB-BEA6B0FAF11B@nokia.com
robin: minutes approved
policy segment
<darobin> action-50?
<trackbot> ACTION-50 -- Richard Tibbett to add security/privacy
considerations to Contacts API inspired from Geolocation -- due
2009-11-10 -- PENDINGREVIEW
<trackbot> [13]http://www.w3.org/2009/dap/track/actions/50
[13] http://www.w3.org/2009/dap/track/actions/50
<darobin> trackbot, close action-50
<trackbot> ACTION-50 Add security/privacy considerations to Contacts
API inspired from Geolocation closed
richt: everybody should review the work by the Geolocation WG
robin: any updates from the editorial pool?
paddy: took an action in BONDI F2F to provide use cases into the
policy requirements doc
... action to be completed by the end of next week
dom: features and capabilities, proposal to start creating a
document on those
<dom> [14]Dom’s proposals for first brick of policy framework
[14] http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0169.html
<darobin> laura: I took an action to review that, but I'll do it by
next call
<dom> ACTION: Paddy to provide use cases for the policy requirements
document - due december 11 [recorded in
[15]http://www.w3.org/2009/12/02-dap-minutes.html#action01]
<trackbot> Created ACTION-69 - provide use cases for the policy
requirements document [on Paddy Byers - due 2009-12-11].
API segment
<Suresh> only via IRC for another 30mins
Contacts
robin: there has been an update to the contacts API
<dom> [16]Contacts API updated
[16] http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0246.html
robin: 1) list of fields
... 2) maturity level
<dom> [17]Contacts API draft
[17] http://dev.w3.org/2009/dap/contacts/
<dom> +1 to trimming down properties for v1
richt: 1) we should have a reduced number of fields
<Suresh> +1
<BryanSullivan> OK, but We need to describe how to extend the field
set
<dom> [18]Robin’s analysis of supported fields across existing
contacts APIs
[18] http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0010.html
<BryanSullivan> This should not repeat the "distributed
extensibility" debate - we need to be more practical here
richt: robin's proposal in the mailing list is good
... potential issues: we loose some requirements
<darobin> ACTION: Richard to propose the list of fields for Contacts
[recorded in
[19]http://www.w3.org/2009/12/02-dap-minutes.html#action02]
<trackbot> Created ACTION-70 - Propose the list of fields for
Contacts [on Richard Tibbett - due 2009-12-09].
richt: will make a proposal on the list about which fields to
drop/keep
Bryan_Sullivan: we need ot be sure we extend this set
... we need to describe how to extent this set of fields
... and make it available to the developers, users of the APIs
<BryanSullivan> +1 to vendor-specific prefixes as one approach to
extensibility - but we need to state this option clearly in the spec
AnssiK: if we give recommendations about the fields to use, it might
work
<Zakim> darobin, you wanted to point out existing extension
approaches
robin: it would be a good idea to mention it as a mechanism
... but not as a normative requirement
<dom> PROPOSED RESOLUTION: the Contacts API provides a set of core
properties that need to be supported, and suggests a prefix-based
extensions mechanism for additional properties
robin: is not something you can test
BryanSullivan: thinks it is testable
richt: vendor specific prefixes are a good idea
robin: any objections to including a note in the spec saying what
the extensions should do?
arve: do we actually need to mention extensibility? the CSS spec
doesn't actually tell you how to do that
robin: it doesn't cost anything to say so and it helps reaching
consensus
<darobin> +1 to richt
<darobin> richt: this is about common attributes, and if OMA
attributes become common, we'll support those
RESOLUTION: the Contacts API provides a set of core properties that
need to be supported, and suggests a prefix-based extensions
mechanism for additional properties
<BryanSullivan> re Richard's point about extensions, we expect that
there will be extensions quickly if the basic set of properties is
not extensible in a web runtime - independent way. we need the
ability to support vocabularies such as OMA CAB (Converged Address
Book)\
<BryanSullivan> This is needed without having to design each device
web runtime to suppor the specific properties of the native client
(which can change, and be a "default" or other as the "current"
client).
<dom> [ok, the roadmap for contacts mentions "Jan 2010" for contacts
API [20]http://www.w3.org/2009/dap/#roadmap]
[20] http://www.w3.org/2009/dap/#roadmap
richt: prefers to keep it as it is, filtering at name attribute
robin: agrees
<BryanSullivan> In essence we should have the ability to deploy web
runtimes on any device, and have the property vocabulary supported
by the address book client transparently supported by the API. This
is the approach to be taken by AT&T in our products and devices, at
least.
robin: in future, better filtering available
richt: will be putting this in the update this week
Capture API
<dom> [21]First stab at the Capture API (aka Camera API) from Tran,
Dzung D
[21] http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0025.html
<darobin> [22]http://dev.w3.org/2009/dap/camera/Overview.html
[22] http://dev.w3.org/2009/dap/camera/Overview.html
<dom> [23]Editors draft of Capture API
[23] http://dev.w3.org/2009/dap/camera/
robin: one of the issues arised, currenlty no way of setting
requirements
<Dzung_Tran> Sorry, I haven't read all the email threads, what do
you mean of setting requirements?
robin: either we get rid of the supported ?? formats, or we keep
them
... personally, preferred ot keep it simple
<Dzung_Tran> Oh, the different resolutions
<arve> there's crosstalk
<dom> dom: +1 to keeping setting the parameter on the device for v2
<dom> ... we need to keep a away to determine whether a device
supports recording a type of input at all, though
<dom> ... (which supported*Formats allow to do indirectly)
<Dzung_Tran> how do you select which resolution you want to take the
image?
<Zakim> darobin, you wanted to talk about alternatives for detection
<Dzung_Tran> Are you suggesting for version 1 just default
<dom> Dzung_Tran, I think the user would select the resolution in
the native app
robin: we could have simple methods, or not having methods present
(don't really like that one)
<darobin> robin: we could have canCaptureXXX
<Dzung_Tran> I guess that would be fine. We need to put that in the
spec as an assumption.
<maxf> +1 to <input type=photo>
<Zakim> darobin, you wanted to point out programmatic triggering
darobin: advantage of the input file even if it requires some sort
of prompting
arve: the camera and all the capture devices basically are just
addressable resources, this should be done in a different way as the
current draft does
<arve> <video src="URI_FOR_CAMERA_RESOURCE">
<darobin> ACTION: arve to make a strawman proposal about what he
things the capture should be [recorded in
[24]http://www.w3.org/2009/12/02-dap-minutes.html#action03]
<trackbot> Created ACTION-71 - Make a strawman proposal about what
he things the capture should be [on Arve Bersvendsen - due
2009-12-09].
<dom> so I guess a question that arve raises (and in which I see
merit) is: is the added value of a specific API to get
pictures/sounds/videos from an external app worth the efforts?
<dom> [I think the notion that widgets might want to run
non-interactive processes is something we are coming back to again
and again]
<darobin> [I agree, I'd like to use arve's on-list proposal to
ferret that one out]
<Dzung_Tran> My thinking is that the API would access the camera
device and not an external app
BryanSullivan: we need to be sure that the method of capturing an
image etcdoes not mandate user involvement
<BryanSullivan> if <input type=photo> mandates user involvement then
it does not meet the requirements
<dom> Dzung_Tran, the current draft reads "Launch device native
camera application for taking image(s)." for captureImage, for
instance
<richt> I made a proposal on the list to support both <input ...>
and programmatic APIs within the same spec. Is it of relevance here?
<dom>
[25]http://dev.w3.org/2009/dap/camera/#widl-Capture-captureAudio
[25] http://dev.w3.org/2009/dap/camera/#widl-Capture-captureAudio
robin: suggests that Arve makes proposal to the list and Bryan to
provide arguments back
<Dzung_Tran> Yes, that was wrong
<Dzung_Tran> I will update the sentence
<marcin> richt, +1. I assume some X0% of the (sub)-interfaces should
be reusable
robin: people should review the spec by the end of next week
<richt> Marcin, that is my proposal.
<dom> Dzung_Tran, there are other aspects of the API that make this
more or less implied (e.g. the limit and duration parameters)
maxf: earlier this week created a wiki page
<dom> arve, could you put your comment on record (not /me)? and
start a thread on that question as well on the ml?
<dom> [26]Wiki page on SysInfo
[26] http://www.w3.org/2009/dap/wiki/SysInfo
maxf: I wrote the battery section of the spec according to those
principles (copy the moto of Geo WG)
<dom> [27]SysInfo draft
[27] http://dev.w3.org/2009/dap/system-info/
<darobin> [28]http://dev.w3.org/2009/dap/camera/Overview.html
[28] http://dev.w3.org/2009/dap/camera/Overview.html
<darobin> bah
maxf: specially interested in the battery section
<darobin> what dom said :)
<dom> [29]Battery API
[29] http://dev.w3.org/2009/dap/system-info/#power
<arve> Rewinding to Camera: I guess what I'm saying is that the
current proposal is not a proper camera API, nor does it offer
anything over <input type="file" accept="image/jpeg">
maxf: regarding marturity, the criteria needs to be fulfilled should
be an agreement on the overall list of APIs
... will submit a refined list
... at most 10 items
... that will be a big stop towards FPWD
... in two weeks a call for FPWD could be possible
<richt> arve, could you comment on this thread on the ml?
[30]http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0
005.html (regardless of the output of the actual semantics that
could be used)
[30] http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0005.html
<darobin> [31]http://dev.w3.org/2009/dap/device/
[31] http://dev.w3.org/2009/dap/device/
core devices
robin: defines an empty device interface
... if people support it we could move to publish it soon
<Zakim> dom, you wanted to suggest publishing it at the same time as
the first api that uses it
dom: it is a useful spec to have
<marcin> arve, re "does not offer anything over ...". I think that
the possibility for fully programmatic character of the API is
different from <input>.
richt: does each spec need to hook into that?
robin: if you use a navigator.device, then yes
<marcin> arve, captureXXX() is an equivalent to clicking on <input>.
<richt> is this ok?
[32]http://dev.w3.org/2009/dap/contacts/#devicecontacts-interface
[32] http://dev.w3.org/2009/dap/contacts/#devicecontacts-interface
robin: but the hooking is fairly straighforward
<dom> richt, looks ok at a glance
dom: yes, you do need the hooking
<darobin> "Objects implementing the NavigatorDevice interface (e.g.
the window.navigator.device object in Web browsers [NAVIGATOR])
provide access to the Capture interface through the Capture
interface . An instance of Capture would be then obtained by using
binding-specific casting methods on an instance of NavigatorDevice."
<dom> (vastly inspired from the geolocation API :)
<richt> me too in the Contacts API :-)
<marcin> arve, and this could be subject to policy decision. The
policy effect of prompt-web would support only <input>, whereas
captureXXX() would be effective within widget-environment policies.
<dom> +1 to try to keep a consistent structure
richt: general structure of the docs, do we want a specific
structure? (for ex. use cases in the annex...)
... will propose something to the list, something simple
<Dzung_Tran> A general outline structure would be great. Make
editors life easier
<dom> ACTION: rich to propose a structure for a template for API
specs [recorded in
[33]http://www.w3.org/2009/12/02-dap-minutes.html#action04]
<trackbot> Sorry, couldn't find user - rich
suresh: calendar API, working with richt, trying to determinte the
use cases
... use cases an requirements
richt: we also had a discussion about the attributes
... related to the contacts API discussion on attributes
<Zakim> dom, you wanted to ask about other priority APIs and to talk
on calendar properties
<Dzung_Tran> You can just create another directory under CVS and
move the file or check it in again
<arve> dom, as a general policy, yes
robin: we should go through the fields in the list, being very
careful if reducing the number
<darobin> Laura_Arribas, it's online so no need to capture it :)
<darobin> bah
<arve> I really don't want us to reinvent the wheel
<arve> again
Summary of Action Items
[NEW] ACTION: arve to make a strawman proposal about what he things
the capture should be [recorded in
[34]http://www.w3.org/2009/12/02-dap-minutes.html#action03]
[NEW] ACTION: Paddy to provide use cases for the policy requirements
document - due december 11 [recorded in
[35]http://www.w3.org/2009/12/02-dap-minutes.html#action01]
[NEW] ACTION: rich to propose a structure for a template for API
specs [recorded in
[36]http://www.w3.org/2009/12/02-dap-minutes.html#action04]
[NEW] ACTION: Richard to propose the list of fields for Contacts
[recorded in
[37]http://www.w3.org/2009/12/02-dap-minutes.html#action02]
--
Robin Berjon
robineko — hired gun, higher standards
http://robineko.com/
Received on Wednesday, 2 December 2009 16:08:06 UTC