W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

Minutes 2009-12-02

From: Robin Berjon <robin@robineko.com>
Date: Wed, 2 Dec 2009 17:07:30 +0100
Message-Id: <1A64C4DA-7C80-4E49-9987-6F51E89E05E7@robineko.com>
To: public-device-apis@w3.org
Hi all,

many thanks to Laura for these minutes!



In text:


      [1] http://www.w3.org/

                               - DRAFT -

          Device APIs and Policy Working Group Teleconference

02 Dec 2009


      [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


          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


          Robin Berjon

          Laura Arribas


     * [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

   <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

   <arve> because he doesn't see the value of the proposal over <input

   <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

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


   <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


     [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

   <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


   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

   <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

   <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

   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

   <Zakim> darobin, you wanted to point out existing extension

   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

   <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

   <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"

   <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

   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

   <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
   ... 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

   <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

   <trackbot> Created ACTION-71 - Make a strawman proposal about what
   he things the capture should be [on Arve Bersvendsen - due

   <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

   <richt> I made a proposal on the list to support both <input ...>
   and programmatic APIs within the same spec. Is it of relevance here?


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

   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

   <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
   [NEW] ACTION: Paddy to provide use cases for the policy requirements
   document - due december 11 [recorded in
   [NEW] ACTION: rich to propose a structure for a template for API
   specs [recorded in
   [NEW] ACTION: Richard to propose the list of fields for Contacts
   [recorded in

Robin Berjon
  robineko ó hired gun, higher standards
Received on Wednesday, 2 December 2009 16:08:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC