Device APIs Working Group Teleconference -- 28 Sep 2011

<trackbot> Date: 28 September 2011

<Claes> aadd is Claes

<scribe> scribenick: Josh_Soref

Introductions

zakari: my name is zakari
... i work for Intel

zakari: i used to work for Nokia
... i'm working on tizen
... defining and creating web apis for tizen

clarke: clarke stevens from cable labs
... i'm the moderator for XXX
... i'm the technical chair of upnp
... took over for 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

TPAC

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

Minutes approval

dom: we know who will be in the room

<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

Battery

<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, 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 xxx3

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> evised 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 lazlo 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

<fjh> Opera proposal updated, "web page can request multiple service types up front and receive multiple service types in the callback ", see

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

<fjh> use case, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0095.html (Dave Raggett)

<fjh> filtering by context, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0097.html (Dave Raggett)

fjh: 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

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

clarke: we'll be submitting it soon

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

<darobin> richt: there are sort of design differences, it's not a competition though happy to find a middle ground

<darobin> ... opera cares a lot about optin

<darobin> ... webinos relies on its security framework, which is questionable in a browser

<darobin> ... we are sitting down with webinos, SE tomorrow to figure it out

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

<fjh> darobin: should WG maintain a summary of use cases, either document or wiki or in some manner?

<fjh> darobin: need this for Web and TV coordination as well

<fjh> darobin: volunteers?

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

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

<fjh> darobin: asks about implementation

<fjh> clarke: plan to share before TPAC. implemented as Java applet, tested on all browsers

<fjh> clarke: should know how it works where soon. works on windows, mac, linux and major browsers

<fjh> clarke: includes both UPnP and Zeroconf

<fjh> 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,_Santa_Clara_%28TPAC%29]

<fjh> clarke: following spec working on with Opera

<fjh> clarke: 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

<Josh_Soref_> ScribeNick: Josh_Soref

<fjh> bryan: API design issue is on how high or low level

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

bryan: 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 the
... XXX5 committee

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

WebIntents

fjh: 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
... Streams is relevant to Camera for capture

TPAC F2F

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

fjh: I put together a wiki page
... we need to know well in advance what we're doing

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

[ scribe will need to % encode commas to make the links happy ]

fjh: 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

<fjh> acl anssik

AnssiK: a couple of weeks ago there was a proposal sent to the list

<fjh> s/acl member:anssik//

AnssiK: 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
... Contacts, i think josh sent something

Contacts

<fjh> josh_Soref: issue is non-portable names with internationalization, see http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0128.html

<fjh> josh_soref: names used for search or for display

<fjh> josh_soref: search should be able to handle multiple results, hence split not needed, so just store display names

<fjh> josh_soref: could display multiple display names, a decision to be made

<fjh> josh_soref: user agent needs mechanism for selection of names as well

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

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

<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

<ernesto_jimenez> ernesto_jimenez: 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

darobin: I know that mozilla is implementing a contacts api
... and they started from ours
... i don't know its status

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

darobin: or whether it will be ready in time for TPAC

I have part of a commitment from our group to do work

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

scribe: eventually, but i don't have anything like a schedule

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

- DRAFT -

Device APIs Working Group Teleconference

28 Sep 2011

Attendees

Contents