Device APIs and Policy Working Group Teleconference

 

 

<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> Tlr's invitation to public-web-security mailing list

robin: Thomas sent an e-mail about the web security mailing list

<darobin> 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> 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> Dom’s proposals for first brick of policy framework

<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 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> Contacts API updated

robin: 1) list of fields
... 2) maturity level

<dom> Contacts API draft

<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> Robin’s analysis of supported fields across existing contacts APIs

<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 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 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> First stab at the Capture API (aka Camera API) from Tran, Dzung D

<darobin> http://dev.w3.org/2009/dap/camera/Overview.html

<dom> Editors draft of Capture API

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 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> 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> Wiki page on SysInfo

maxf: I wrote the battery section of the spec according to those principles (copy the moto of Geo WG)

<dom> SysInfo draft

<darobin> http://dev.w3.org/2009/dap/camera/Overview.html

<darobin> bah

maxf: specially interested in the battery section

<darobin> what dom said :)

<dom> Battery API

<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? http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0005.html (regardless of the output of the actual semantics that could be used)

<darobin> 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? 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 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