See also: IRC log
<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
<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
<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
<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
<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