Device APIs Working Group Teleconference

28 Sep 2011


See also: IRC log


Robin_Berjon, Frederick_Hirsch, Ernesto_Jimenez, Sakari_Poussa, Dzung_Tran, Claes_Nilsson, Dominique_Hazael-Massieux, Anssi_Kostiainen, Josh_Soref, Kihong_Kwon, Bryan_Sullivan, Cathy_Chan, Rich_Tibbett
Robin_Berjon, Frederick_Hirsch


<trackbot> Date: 28 September 2011

<scribe> scribenick: Josh_Soref


sakari: my name is Sakari Poussa
... I work for Intel
... I used to work for Nokia on MeeGo
... I'm working on Tizen - https://www.tizen.org/
... defining and creating web apis for Tizen

[ MeeGo was a joint Intel/Nokia effort, which was recently rebranded as Tizen ]

clarke: Clarke Stevens from CableLabs
... I'm the moderator for Media pipeline task force
... I co-edit the Discovery API submitted with Opera
... I'm the technical chair of upnp
... I took over from Cathy


<fjh> TPAC registration reminder, deadline 10 Oct hotel, 14 Oct registration, http://www.w3.org/wiki/TPAC2011

<fjh> http://lists.w3.org/Archives/Member/member-device-apis/2011Sep/0003.html

fjh: Reminder to register

<fjh> need to create a questionnaire for TPAC attendance, in person and remote

fjh: I don't know if we have a questionaire
... I don't know who can do it

darobin: team contact or chair can

fjh: ok, I'll do it

dom: We know who will be in the room

Minutes approval

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/att-0081/minutes-2011-09-14.html

<fjh> proposed RESOLUTION: Minutes from 14 September 2011 are approved

RESOLUTION: Minutes from 14 September 2011 are approved


<fjh> Updated version of the Battery Status Event spec was released as new Working Draft: http://www.w3.org/TR/2011/WD-battery-status-20110915/

<fjh> Comments, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0082.html

<fjh> Mozilla battery wiki -> https://wiki.mozilla.org/WebAPI/BatteryAPI, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0116.html (Robin)

fjh: We have a new draft published
... and Mozilla has a draft implementation

anssik: We have two implementations
... I think it's time to align
... based on them
... Mozilla has some minor deviations
... the next step forward is to get official feedback
... Kihong_Kwon did the implementation
... based on interest from implementers
... I think we can quickly converge
... I think theres some notes on the Mozilla wiki
... they've documented their design
... which is implicit feedback
... I'd rather they sent explicit feedback to a list
... there's also their bug tracker (bugzilla)
... from Kihong_Kwon, I'd like to receive your feedback too
... I understand you're based on an earlier draft

<darobin> Kihong_Kwon?

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0125.html

Device Status Task Force

<darobin> dom: based on feedback from members and implementers we created the Device Status TF

<darobin> ... make sure that you sign up for it if you're interested in Battery and Network Info

fjh: We should also figure out what to do with network info

richt: just wondering about IP commitment
... for the Task Force

fjh: I think it's either WG commitment
... or an explicit commitment

<Zakim> darobin, you wanted to comment on Network Info

fjh: that's a problem for W3C process, not a WG to determine

darobin: in general
... the commitment outside of WG gives a little bit less rights
... but it's just a strange workaround
... on network information
... I haven't found anyone with a reason for why it's useful

<fjh> IPR commitment for members of task force is same as for WG, either through WG membership or explicit IPR licensing committment

darobin: looking at Mozilla's work
... I don't think they're able to see a use either

Feature Permissions API

<fjh> Revised example, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0006.html (Wonsuk)

<fjh> ACTION-435 Update the Permissions draft based on f2f discussion and summary email from Robin in planning for FPWD Laszlo Gombos

<fjh> ISSUE-109 We need solid use cases for Feat Perms if it's going to fly

fjh: I don't think Laszlo is on the call
... I think people should join the task force
... which most of us have


fjh: Call for comments, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0087.html
... Opera proposal updated, "web page can request multiple service types up front and receive multiple service types in the callback", see
... avoiding polling, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0108.html
... use case, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0095.html (Dave Raggett)
... filtering by context, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0097.html (Dave Raggett)
... there was a lot of discussion
... Richt, did you want to speak?

richt: I made this proposal based on the web and tv group in Opera
... if there's little interest in getting this in the group
... then I'm not interested in working on it ??
... I'd like to see an implementation
... I'd like to see it come from Opera
... it will come, but there's a lot in front of it

clarke: we have an implementation
... it's preliminary
... we'll be submitting it soon

<Zakim> fjh, you wanted to ask about range of lower level protocols and dave's work

fjh: I believe you have a submission
... maybe cathy has more details
... I believe there are two lower protocols
... feedback on the list talks about integrating

<richt> feedback to Dave Raggett http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0098.html

fjh: I believe there were questions about accessing lower layers

richt: there are sort of design differences, it's not a competition though happy to find a middle ground
... Opera cares a lot about optin
... webinos relies on its security framework, which is questionable in a browser
... we are sitting down with webinos, SE tomorrow to figure it out
... we're working with everybody, if it means complete redesign so be it

<Zakim> darobin, you wanted to ask if we should maintain a use cases list and to ask about putting hands on implementation

darobin: should WG maintain a summary of use cases, either document or wiki or in some manner?
... need this for Web and TV coordination as well
... volunteers?

clarke: attended web and tv meeting last week, agreed to submit use cases to DAP, meet jointly at TPAC?

darobin: an informal way of doing submission would work well

<Dzung_Tran> I could check with the TV group at Intel and the rep there

darobin: asks about implementation

clarke: plan to share before TPAC. implemented as Java applet, tested on all browsers
... should know how it works where soon. works on windows, mac, linux and major browsers
... includes both UPnP and Zeroconf

richt: would like to see how permissions work with this and UI

<darobin> [btw, shared brain for agenda preparation is at http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011%2C_Santa_Clara_%28TPAC%29]

clarke: following spec working on with Opera
... use custom XHR for cross-origin

<Zakim> bryan, you wanted to point out agnostic design may not fulflll the needs of the CE community, per comments in the Web and TV workshop

<darobin> http://www.w3.org/mid/CA9F9132.1474B%25blsaws@gmail.com -> suggestion from Bryan

bryan: API design issue is on how high or low level
... it seems there was a desire to have access to the low level protocol
... that is a key issue
... I don't think that a totally agnostic api will meet the needs of
... certain groups

clarke: we believe we can implement a generic api
... that will work for zeroconf / upnp / ...
... with a security model

richt: this discussion has been going on for a while in web&tv at Opera
... I think it makes sense to try a model
... and see how the use cases work with it

fjh: I think we should have more discussion on the list


<AnssiK> Art's Q: http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0121.html

fjh: I think Art sent a question
... some confusion about terminology
... there's the old google web intents
... and a new web intents

darobin: I was following the discussion on web apps
... and the issue with Google/MS joining
... is RF
... we need to make it easy for other vendors to join
... without having to write off IP if they don't want to

fjh: It doesn't sound like this is stuff for the WG to discuss
... I wonder if we need to technically clarify the work
... it seems we have two different groups with different proposals
... and they're progressing differently
... I'm not sure of the value in comparing the older stuff vs. the new
... beyond the political issue of where the work should be done
... I believe a number of us follow both groups

Claes: wrt Web Introducer
... it seems that web intents is now the solution which has the most support
... the concepts are very similar when it comes to applications
... they solve the same use cases
... basically they are very similar from an application developer's point of view
... and from the user's point of view

fjh: so basically the solve the same things in a fairly similar manner

Claes: I'm preparing a wiki page covering the Opera proposal, and the webinos proposal
... and I'll try to add the intents proposal
... it will be on the DAP wiki

Streams API

<darobin> ACTION: Robin to reply to ArtB about Web Intents [recorded in http://www.w3.org/2011/09/28-dap-minutes.html#action01]

<trackbot> Created ACTION-455 - Reply to ArtB about Web Intents [on Robin Berjon - due 2011-10-05].

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0105.html

darobin: It's not something we need to jump on right away
... Str eams is relevant to Camera for capture


<fjh> http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011%2C_Santa_Clara_(TPAC)

fjh: I put together a wiki page
... we need to know well in advance what we're doing
... Web and TV
... if people have things that should be discussed, please add to the wiki

<darobin> +1 to direct editing

fjh: or send to the list to talk about it

AnssiK: a couple of weeks ago there was a proposal sent to the list
... re battery status

<AnssiK> http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0129.html

AnssiK: should we discuss that at TPAC or on this call?

fjh: I couldn't tell if you wanted that in the Testing WG

AnssiK: the reason was that the browser testing tools already incorporate this functionality
... it's about exposing that api to developers
... the Testing WG exposes console.log

fjh: darobin, I'm not sure what you think about this

darobin: for something like that, the first step would be to look to see if there's any interest from implementers
... if there's no interest, then adding a spec, is just adding a spec
... people do run out of memory
... one thing to do is to discuss with Mozilla on the DAP task force
... see what Mozilla has to say
... obviously if other implementers are interested

AnssiK: do you know the status of charles?
... is he in a position to comment as an implementer?

darobin: currently, I don't know

AnssiK: maybe use the TF as a vehicle

fjh: I think people should directly edit the TPAC-DAP-F2F wiki


fjh: Contacts, I think Josh_Soref sent something

Josh_Soref: issue is non-portable names with internationalization, see http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0128.html
... names used for search or for display
... search should be able to handle multiple results, hence split not needed, so just store display names
... could display multiple display names, a decision to be made
... user agent needs mechanism for selection of names as well

ernesto_jimenez: I've checked contacts APIs from Android, iPhone, Blackberry, office, etc. They usually have a display name, which will be the only reliable attribute for the developer because a contact might not have family/given/middle name at all and the display name might be the email
... the question would be if we expose the structured name (with family, given and middle) apart from the display name, but those attributes might be missing from the backend data, so display_name would be the only reliable attribute for developers anyway

richt: feedback, displayname makes a lot of sense
... for internationalization
... yes, formatting gets lost
... but that's not a big deal
... but if you're going to reimport that back
... you've lost it
... it's impossible to design a contacts api that everyone loves
... I've been thinking of other ways to do this
... a container way
... it's hard to write this in a way that makes sense for everyone

<richt> 'it's impossible to design a contacts api that everyone loves' is the lesson learnt. Recent thinking is on allowing anyone to write their own contacts apis and expose those as services to the web browser (ala, Web Intents, Web Introducer, Opera's Service Discovery & Messaging proposal)

Android has two apis, an old one http://developer.android.com/reference/android/provider/Contacts.html and a new one: http://developer.android.com/reference/android/provider/ContactsContract.html

darobin: I know that Mozilla is implementing a contacts api
... and they started from ours
... I don't know its status
... or whether it will be ready in time for TPAC

<fjh> we need implementation work on contacts in order to progress it

Josh_Soref: I have part of a commitment from our group to do work
... eventually, but I don't have anything like a schedule

<darobin> [if everyone does their own Contacts service API we're not better off than we are today actually]

<AnssiK> [ Mozilla's Contacts impl: https://bugzilla.mozilla.org/show_bug.cgi?id=674720 ]

<ernesto_jimenez> [ Phonegap's impl: http://docs.phonegap.com/phonegap_contacts_contacts.md.html#Contact ]


<darobin> +1

<richt> thanks Josh_Soref for scribing

Summary of Action Items

[NEW] ACTION: Robin to reply to ArtB about Web Intents [recorded in http://www.w3.org/2011/09/28-dap-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $