[![W3C][1]][2] # Device APIs Working Group Teleconference ## 28 Sep 2011 [Agenda][3] See also: [IRC log][4] ## Attendees Present 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 Regrets Niklas_Widell Chair Robin_Berjon, Frederick_Hirsch Scribe Josh_Soref ## Contents * [Topics][5] 1. [Introductions][6] 2. [TPAC][7] 3. [Minutes approval][8] 4. [Battery][9] 5. [Device Status Task Force][10] 6. [Feature Permissions API][11] 7. [Discovery][12] 8. [WebIntents][13] 9. [Streams API][14] 10. [TPAC F2F][15] 11. [Contacts][16] 12. [AoB][17] * [Summary of Action Items][18] * * * Date: 28 September 2011 scribenick: Josh_Soref ### Introductions 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/][19] ... 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 ### TPAC TPAC registration reminder, deadline 10 Oct hotel, 14 Oct registration, [http://www.w3.org/wiki/TPAC2011][20] [http://lists.w3.org/Archives/Member/member-device- apis/2011Sep/0003.html][21] fjh: Reminder to register 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 [http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/att-0081/minutes-2011-09-14.html][22] proposed RESOLUTION: Minutes from 14 September 2011 are approved **RESOLUTION: Minutes from 14 September 2011 are approved** ### Battery Updated version of the Battery Status Event spec was released as new Working Draft: [http://www.w3.org/TR/2011/WD-battery-status-20110915/][23] Comments, [http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0082.html][24] Mozilla battery wiki -> [https://wiki.mozilla.org/WebAPI/BatteryAPI][25], [http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0116.html][26] (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 Kihong_Kwon? [http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0125.html][27] ### Device Status Task Force dom: based on feedback from members and implementers we created the Device Status TF ... 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 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 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 Revised example, [http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0006.html][28] (Wonsuk) ACTION-435 Update the Permissions draft based on f2f discussion and summary email from Robin in planning for FPWD Laszlo Gombos 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 ### Discovery fjh: Call for comments, [http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0087.html][29] ... 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][30] ... use case, [http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0095.html][31] (Dave Raggett) ... filtering by context, [http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0097.html][32] (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 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 feedback to Dave Raggett [http://lists.w3.org/Archives/Public/public- device-apis/2011Sep/0098.html][33] 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 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 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 [btw, shared brain for agenda preparation is at [http://www.w3.org/2 009/dap/wiki/F2F_Agenda_3-4_November_2011%2C_Santa_Clara_%28TPAC%29][34]] clarke: following spec working on with Opera ... use custom XHR for cross-origin 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 [http://www.w3.org/mid/CA9F9132.1474B%25blsaws@gmail.com][35] -> 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 ### WebIntents Art's Q: [http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0121.html][36] 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 **ACTION:** Robin to reply to ArtB about Web Intents [recorded in [http://www.w3.org/2011/09/28-dap-minutes.html#action01][37]] Created ACTION-455 - Reply to ArtB about Web Intents [on Robin Berjon - due 2011-10-05]. [http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0105.html][38] darobin: It's not something we need to jump on right away ... Str eams is relevant to Camera for capture ### TPAC F2F [http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011%2C_Santa_C lara_(TPAC)][39] 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 +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 [http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0129.html][40] 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 ### Contacts 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][41] ... 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 '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][42] and a new one: [http://developer.android.com/reference/android/provider/Contac tsContract.html][43] 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 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 [if everyone does their own Contacts service API we're not better off than we are today actually] [ Mozilla's Contacts impl: [https://bugzilla.mozilla.org/show_bug.cgi?id=674720][44] ] [ Phonegap's impl: [http://docs.phonegap.com/phonegap_contacts_contacts.md.html#Contact][45] ] ### AoB +1 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][37]] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][46] version 1.135 ([CVS log][47]) $Date: 2009-03-02 03:52:20 $ [1]: http://www.w3.org/Icons/w3c_home [2]: http://www.w3.org/ [3]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0127.html [4]: http://www.w3.org/2011/09/28-dap-irc [5]: #agenda [6]: #item01 [7]: #item02 [8]: #item03 [9]: #item04 [10]: #item05 [11]: #item06 [12]: #item07 [13]: #item08 [14]: #item09 [15]: #item10 [16]: #item11 [17]: #item12 [18]: #ActionSummary [19]: https://www.tizen.org/ [20]: http://www.w3.org/wiki/TPAC2011 [21]: http://lists.w3.org/Archives/Member/member-device- apis/2011Sep/0003.html [22]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/att-0081/minutes-2011-09-14.html [23]: http://www.w3.org/TR/2011/WD-battery-status-20110915/ [24]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0082.html [25]: https://wiki.mozilla.org/WebAPI/BatteryAPI [26]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0116.html [27]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0125.html [28]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0006.html [29]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0087.html [30]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0108.html [31]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0095.html [32]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0097.html [33]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0098.html [34]: http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011%2C_Santa _Clara_%28TPAC%29 [35]: http://www.w3.org/mid/CA9F9132.1474B%25blsaws@gmail.com [36]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0121.html [37]: http://www.w3.org/2011/09/28-dap-minutes.html#action01 [38]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0105.html [39]: http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011%2C_Santa _Clara_(TPAC) [40]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0129.html [41]: http://lists.w3.org/Archives/Public/public-device- apis/2011Sep/0128.html [42]: http://developer.android.com/reference/android/provider/Contacts.html [43]: http://developer.android.com/reference/android/provider/ContactsContract.html [44]: https://bugzilla.mozilla.org/show_bug.cgi?id=674720 [45]: http://docs.phonegap.com/phonegap_contacts_contacts.md.html#Contact [46]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [47]: http://dev.w3.org/cvsweb/2002/scribe/