See also: IRC log
<trackbot> Date: 10 July 2012
<fjh> Meeting: Device APIs Working Group Face-Face 10-12 July 2012, Burlington MA
<scribe> Scribe: Josh_Soref
fjh: restrooms are outside
... There's a cafeteria down the hall
... We should use it
jhawkins: James Hawkins
... At Google
... I'm interested in WebIntents
dsr: Dave Raggett
... W3C
... I'm measured on recommendations per minute
jgiraud: Jerome Giraud
... Orange
... Global interest apis
Milan: Milan Patel
... Huawei
... Standards, W3C is in my area
... Within DAP, WebIntents are my main interest
Cathy: Cathy Chan, Nokia
Lgombos: Laszlo Gombos
... Nokia
richt: Richard Tibbett
... Opera
... I lead extensions and device apis
... Interested in WebIntents
... And sensors
<Paul_Kinlan> Paul_Kinlan is joining now, just need to find a room
Josh_Soref: Josh Soref
... interested in web intents.
fjh: Frederick Hirsch, Nokia, co-chairing this WG, interested in everything in this group
darobin: Robin Berjon
... co-chairing with Frederick and interested in everything.
youenn: Youenn Fablet, Canon, interested in Web Intents and media capture API
kensaku: Kensaku Komatsu
... interested in Web Intents
naoyuki: Naoyuki Sato, Sony
... interested in combination of web with home networks
aizu: Hiroyuki Aizu
... interest is in Web Intents / integration of home network / cloud services.
... interested in 2 things: inter-device communication based on e.g. Web Intents. Printing from camera or displaying camera content on TV.
... second interest: an advanced media capture API. A Camera API.
... Canon hope to officially be a member of DAP shortly. Currently attending as an observer.
jun: Jun Fujisawa, Canon
dcheng3: Diana Cheng, Vodafone
... interested in Web Intents, Network Information API, Sensors.
shan: Soonbo Han, LG Electronics, main interest is Web Intents
Wonsuk: Wonsuk Lee, Samsung
... participate in Tizen group. Samsung interested in all of the Device APIs.
... Contact and Calendar APIs are particularly important to us.
... Tizen wants to bring more advanced APIs to the web for richer experiences.
... Working on Tizen as well. Working on Gallery API based on Web Intents. Interested in additional Web Intents-based APIs.
Jungkee: Jungkee Song
nwidell: Niklas Widell
... interest in Web Intents, Sensor APIs and Capture parts.
Paul_Kinlan: Paul Kinlan, Google.
... primarily interested in Web Intents.
gmandyam: Giri Mandyam, Qualcomm
Introductions done.
<darobin> "We have particular interest in the work of the Media Capture Task Force, and will also be very interested in the progress of other specifications such as the Network Info API and Web Intents."
[fjh runs through the proposed meeting agenda]
fjh: Any suggestions on the agenda just ping me offline.
Agenda approved.
fjh: Welcome to all new members of the working group.
<darobin> ACTION: dsr to check out why chairs got an email to announce Sony joining group but they're not listed in DBWG [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action01]
<trackbot> Created ACTION-548 - Check out why chairs got an email to announce Sony joining group but they're not listed in DBWG [on Dave Raggett - due 2012-07-17].
<fjh> Approve minutes from 27 June
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Jun/att-0104/minutes-2012-06-27.html
<fjh> proposed RESOLUTION: Minutes from 27 June 2012 are approved
RESOLUTION: Minutes from 27 June 2012 are approved
fjh: we have a draft
... i did a CfC
... no one complained
... i believe Anssi was supportive
... we have a 4 week LC
... there's a 3 week minimum
<fjh> CfC for Last Call: http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0005.html
<fjh> proposed RESOLUTION: publish HTML Media Capture as Last Call on 12 July 2012 with
<fjh> four week Last Call period ending 9 August 2012.
richt: how are we on implementation?
darobin: we have roughly 2 not quite complete
... we might go to CR w/ things AT-RISK
... the HTML INPUT Element extension
... we don't have fully interoperable implementations
... there's a lot of interest in implementing this
... i get the sense from browser implementers that they don't care about the syntax
... everyone says we don't care what it looks
... like
... there's pressure from CoreMob
... dear-dap please ship it
richt: theory should be document current practice
dsr: plh is keen for us as we go to LC
... to get feedback from the HTML WG
darobin: the only feedback from the HTML WG would be "this should be in our spec"
<darobin> [I note that that was a jocular comment]
[ Scribe notes that the HTML WG expressed some interest in California in not owning everything ]
RESOLUTION: publish HTML Media Capture as Last Call on 12 July 2012 with four week Last Call period ending 9 August 2012.
<fjh> Battery in CR http://dvcs.w3.org/hg/dap/raw-file/tip/battery/CR.html ;
<fjh> open actions to produce test cases; ACTION-522, ACTION-523 able to exit CR after 1 July.
fjh: Battery is in CR
<fjh> ACTION-522?
<trackbot> ACTION-522 -- Robin Berjon to write tests for Battery -- due 2012-03-28 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/522
<fjh> ACTION=523?
darobin: Battery is in CR
... i haven't finished updating the testsuite yet
... i'm still updating it
... i hoped to finish by this meeting
... those actions are still open
... i'm making progress
... i hope to exit CR by end of summer
... we have implementations
... a good spec
... half of a test suite
... it all looks good to me
fjh: Anssi will be back
darobin: yes, that will help as well
<fjh> plan is to exit CR at end of summer assuming all goes well
<fjh> Vibration in CR http://www.w3.org/TR/2012/CR-vibration-20120508/ ;
<fjh> open actions to produce test cases; ACTION-523 able to exit CR after 1 July
fjh: i think this is similar to Battery
darobin: i have an action on this from the Test Infrastructure Group
fjh: not CoreMob
<fjh> Proximity - latest editors draft , http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html
fjh: Paul_Kinlan
... i believe you were interested in talking about it
Josh_Soref: I doubt it was Paul_Kinlan
<Paul_Kinlan> It wasn't me
<fjh> proposed ACTION fjh to prepare CfC to publish FPWD of Proximity API specification
darobin: i think it was dougt
fjh: I'll send dougt an email
... is there any objection to publishing a FPWD?
... a FPWD is an indication of progress
... it isn't a commitment to the document as is
... if there are minor questions/comments
... we can either incorporate them
... or into the next draft
PROPOSED RESOLUTION: WG agrees to publish a FPWD of Proximity API specification
fjh: we don't need a short name, do we?
darobin: i think we do
dsr: yes, you do
fjh: we have Proximity in our draft
... i think that's fine
RESOLUTION: Short name for Proximity API will be "Proximity"
fjh: that's the thing people always forget, is the short name
RESOLUTION: WG agrees to publish a FPWD of Proximity API specification with short name "Proximity"
<fjh> ACTION: rberjon to prepare CfC to publish FPWD of Proximity API [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action02]
<trackbot> Created ACTION-549 - Prepare CfC to publish FPWD of Proximity API [on Robin Berjon - due 2012-07-17].
fjh: we have a FPWD
... we have an ED w/ updates
... we have some issues in the Wiki
... jhawkins, you have some updates?
jhawkins: we're really excited about FPWD
... congratulations everyone for helping put that together
... the biggest part was the last F2F in Shenzhen
... wrt the Chrome implementation, we've been working w/ UX to address the bad UI we have
... we're hashing out what the UI will look like
... right now, the feedback we've got from developers
... was that they like the API, but they can't ship if the UI is bad
darobin: do you know when this will be present?
jhawkins: I think this could appear in Chrome 22
... we deprioritize working w/ clients of the API
... we have a list of changes we want
... some dating back to the F2F
... they're nice to haves
... perhaps something we could be productive on here
... (disposition)
... we did a presentation two weeks ago @Google.IO
... it was really exciting
... of all the presentations I attended, it had the longest Q/A session
... we had hallway presentations about it
... we did a Code Lab with 40 developers
... doing a hands on tutorial for writing web intents
... we found a ton of bugs this way
... it was good to get that feedback
<darobin> https://developers.google.com/events/io/sessions/gooio2012/216/
jhawkins: we need to find a way for people to be hands on
... writing demo code
... to tease out some of these bugs
... Related...
... mounir posted the WebActivities counter-proposal
... we could go over them today?
... I think there are some Issues?
fjh: we could go over Explicit Intents
... i think it's sparse in the spec
jhawkins: that's a good point
... the spec has gotten really dense
... after reading it so many times, it's hard to find bugs
... that's a plea for editing help w/ the spec
fjh: are there issues we haven't talked through/thought about?
... i think there are more implications
jhawkins: certainly security/privacy
fjh: my concern with Explicit intents is that it defeats the paradigm
jhawkins: the way we rationalize it
... in our UI, the user can choose in the picker
... it's like a client default
... but the user can go back and pick another service
fjh: so if you're doing photos, and you do an editor thing
... you'd land in the editor, and you could go back?
jhawkins: say inline disposition
... you'd have a link to go back
... [in the UA]
... also for the window disposition
... if you know the popup blocker alert
... in chrome, it's a box on the top right
... we'd have a bar like that which would let the user to pick other things
fjh: the client would set the explicit intent
... all clients could do this normally
... and users could do this path
... there's a privacy risk where data is sent on that fast path
... and the receiving side sees it
... without the user being able to prevent that
jhawkins: that's a concern
fjh: it seems people would maybe choose to do that more often
Paul_Kinlan: if you're building an application with an image editor
... with crop, red-eye removal
... you might build each component using intents
... you make those small components available for external clients
... but you use it for your main app
fjh: sort of like a manifest for an application
... sort of a different UC
dsr: if it's Same-Origin, then that's less of an issue
fjh: i forgot if that section talks about origin
... for explicit intents
jhawkins: this leaves out the possibility of a webintents agent
... you can do that w/ explicit intents
... it could be a picker itself
... we'd lose it if we leave out explicit
... i understand we could be sending out data w/o knowing where it's going
fjh: it seems like we have a great model where we have a user mediated stage
... explicit intents lets you bypass the whole thing
Josh_Soref: could change explicit intent mechanism to open connection, load page, but not share data initially
jhawkins: this is a possibility
... i'd like to point to how Android Intents worked
<jhawkins> Explicit intents designate the target component by its name (the component name field, mentioned earlier, has a value set). Since component names would generally not be known to developers of other applications, explicit intents are typically used for application-internal messages — such as an activity starting a subordinate service or launching a sister activity.
<fjh> not security by obscurity though
Josh_Soref: it sounds like this argues for same-origin
jhawkins: if we have a solution for privacy that are compelling
... the notion of a web-intents Agent
... we've heard it from other people
Jungkee: i have a UC for Gallery API
... we can avoid interaction with explicit intents
... they can just go directly to the service
... like local storage
... an service provider provides explicit service
... and the user doesn't have to pick something
fjh: why wouldn't you want User interaction?
... i don't understand why you'd want that
Jungkee: with explicit, you don't show a picker
fjh: but why wouldn't you want to show the picker?
Jungkee: because the user has to choose the picker before picking the media
... we can give a better UX
fjh: it seems like you're worried about repeated interactions
... you're talking about wanting to remember previous options
... i thought there already was a way to do that without explicit intents
jhawkins: that's correct
Jungkee: if a service provider provides explicit urls
richt: we've also looked at this issue
... it isn't just an issue for web intents
... one solution is accountability through transparency
... we give users/developers the ability to look through data through logs
... that's an informal kind of contract
... it helps
... you can't just push through crazy stuff w/o accountability
... if you do stuff with dev tools
... i think that'll be a factor in trying to solve privacy issues
jhawkins: this came up about 2 weeks ago
... there's an extension in the Chrome Web Store
... it's the Web Intents Debugger
... we want to take that concept and move it into the Web Inspector
... so yeah, we're on the same page with that
richt: there is a way of highlighting and putting pressure on companies to not do stupid things
... if you need to keep your reputation in tact
... it's a way to do this
fjh: not sure how to do that
jhawkins: best practices
... does the speed bump on privacy data address your privacy concerns?
fjh: not sure i remember the speed bump
jhawkins: it shows the destination and gives an explanation
fjh: i think so
Paul_Kinlan: on explicit intents
... we have one relatively big news agency partner
... they want to use explicit intents
... they have twitter, facebook, and other
... they'd like to use the same API for talking to all three sets
... but they'd like to make the actions clear
... but these partners want to have the ability to give the user a seemless experience
... but also give the intents picker
... there are people who are actively looking to use web intents throughout their whole experience
fjh: would that work with the speedbump idea?
Paul_Kinlan: i think it's kind of nice
... i don't think it works right now
<Zakim> Josh_Soref, you wanted to say this sounds like a need for persisted connections to intents
Paul_Kinlan: i think we need delayed delivery
Josh_Soref: agree with frederick, if client makes request to use intent, user agent can persist future requests without repeated picker
... this could apply to speed bump case as well
... also gallery
... thus do not need explicit intent for the gallery use case
richt: the way android intents work, if i set a default intent, it will always use that
... if i then open another provider for that intent
... then the next time i try to trigger that intent
... i'll get the picker
fjh: that makes sense
<Zakim> dsr, you wanted to note that direct binding of app to a component can be done without web intents, so using an explicit intent is presumably to allow user to pick an alternative
Josh_Soref: it's dangerous with spammers, but mostly makes sense
dsr: what's the benefit of using web intents rather than directly
... how do you explain the benefits of using explicit intents
... and the benefit is letting users change their mind
... the benefits are same-origin
... being able to change their mind is still useful
... and for separate origin, there's a different benefit
... we should clarify the benefit
jhawkins: today on the web, it sucks, there's one-one
... intents solves by providing one-to-n
... but we can give them this api which lets them still use one-one
... to emphasize what Paul_Kinlan was saying about a News sight
... feedback from someone AddThis
... is that users won't click on Share buttons unless they see a familiar icon
... they'll even click the share button that isn't facebook-twitter if they see facebook-twitter nearby
... doing this makes the migration path easier
... it removes the burden of using multiple apis
... 2. moving to the semantic web
... with schema.org we have nouns
... with intents, we have verbs
... if you can call the web a search engine, say you're bing
... you can understand which pages are nouns and which are verbs
... you could have the engine put these things together
... bing could put the player together in the front page
... that requires explicit intents
<Zakim> fjh, you wanted to ask whether users understand components of app and can change minds
fjh: it seems like plugging in a random component isn't something the user would be able to fit in well
... it seems likelihood of it working is low
... it makes sense
... but nothing prevents abuse
jhawkins: is it easier?
... you'd have to find something that works somewhere on the web
... maybe we shouldn't gloss over the problem
... using intents to structure your app into components
... maybe it is compelling, maybe it isn't
... it seems to be for android
... maybe we make it special for same-origin-explicit to skip the speed bump
... i'm a little concerned about it
fjh: we got the speed bump, and same-origin
Josh_Soref: should we action jhawkins
... have mail web client which has address book with explclit intent to use that address book
... but I want to use anther book, so first see nothing much, then want to get to other book
... so even with same origin want to go to different address book
... next time get my preferred, not same origin
<Zakim> Josh_Soref, you wanted to say that the web intent inspector matches a requirement i listed a while ago
dsr: the benefit of same-origin is avoid the speed bump
Josh_Soref: but allow for a U-turn
<fjh> a/anther/another/
u-turn is going back from explicit choice to pick after all
Josh_Soref: pleased that people are realizing my previous ideas were good
Paul_Kinlan: for explicit intents
... web intents are typically gated on user actions
... providing a modifier like a shift key to bring up the picker
... so that the user can ask in advance to get the picker
fjh: so if i shift click on a twitter button, i get the picker?
Paul_Kinlan: a u-turn might be a bit awkward
... it might be written in a way to encourage the UA to provide a way to map back to choosing
richt: it's analogous to Open/Open-With
Paul_Kinlan: it could be a browser-user-preference
... where they say never allow explicit intent
fjh: that's something we could record in how the spec works
Josh_Soref: it's basically UA Implementer guidelines
<dsr> (fjh: e.g. a right click for the context menu with a entry for the picker)
fjh: the concern is that the more complexity you add, the more testing
jhawkins: i'm concerned that we should try to solve it some other way
... i'd like to solve shift click
fjh: because the client didn't provide the picker
jhawkins: you don't know that there will be an intent
Josh_Soref: i think U-turn and remembering the choice is the way
jhawkins: i'd like to keep shift-click out
... i think we've solved it otherwise
... but a UA can still do something like it if it likes
richt: have you looked at
... we could use the context menu, did you look at it
... having open with with a pop out menu list
jhawkins: we haven't thought about exactly that
... we've thought about those lines
... one way is to make the browser involved
... like right clicking an image
... share/edit/upload
... and start adding these integration points throughout the browser
... and also services, picking files
... exposing services where you have a button that will call start activity
... being able to right click and select something
... unless you have <button intent=>
... if you have that, i think so
richt: i think that's compelling
jhawkins: say you're in windows and do shift-right-click
... that's more about content
... than where the client is calling start activity
... in a page
... we've talked about declarative invocation of intents
... we could do that at some point
[ Break ]
fjh: 10 minute break and then Lunch
jhawkins: webintents issues wiki
... w3.org namespacing for intents
... web activities
jhawkins: the proposal is to move the namespace to W3.org
<jhawkins> W3.org proposal for namespacing:
<jhawkins> for ACTION: http://www.w3.org/ns/intent#edit
<jhawkins> for type: http://www.w3.org/ns/intent#image
dsr: there was a proposal on W3 Team
... which i'll forward to the DAP ML
jhawkins: if we could drop the 'www.' and make it shorter
... it's 28 characters vs. 22 for webintents
... it's 24 characters if we drop www.
... 'ns/' isn't self documenting and should be removed
darobin: this is 'ns/' because it piggy backs on the namespace for xml
... there's no reason it isn't used for other name spaces
<darobin> http://www.w3.org/ns/intent#edit
<darobin> http://www.w3.org/ns/intent#pick
<darobin> http://www.w3.org/ns/intent#image
<darobin> http://www.w3.org/ns/intent#contact
<darobin> @prefix wi: <http://www.w3.org/ns/intent#>
<darobin> wi:edit a wi:Action
<darobin> wi:pick a wi:Action
<darobin> wi:image a wi:Type
<darobin> wi:contact a wi:Type
darobin: they're awkward and we should drop it
Josh_Soref: we all know browse vendors hate XML and we should do everything to avoid any resemblance to XML
... I don't like ns/
fjh: I don't like it either
richt: I don't either
darobin: for xml ns, it used to be first come first serve
... come up w/ whatever you like
... then someone decided it should be coherent, with a dated namespace
... so we picked years
... so then you had to use 5 years for 5 different xml portions
... then we had pushback to use ns/ instead of random years
... i think we only managed one xml spec in ns/ (widgets -- "very successful")
... we should avoid the clustermess of xml
fjh: the goal is to avoid 'ns/' after '.org/'
Paul_Kinlan: could we have 'intent' as the subdomain?
darobin: that's asking a lot
<fjh> that would make sense: intent.w3.org
Paul_Kinlan: one goal of webintents.org was to have as little after the / as possible
<darobin> [we could just keep webintents.org...]
Paul_Kinlan: using a domain to split things off would be better
jhawkins: there's "action" and "type" and i don't think we should do anything with type
... we're doing type everywhere else
... we already have mime types and schema.org
... are we duplicating schema.org?
... that page would have to have documentation on the type
darobin: it depends on the type
... reusing schema.org for contacts doesn't work
... schema.org has different types for people and companies
jhawkins: that's a good point
Paul_Kinlan: from what jhawkins was saying
... schema.org didn't exist
... when we looked at webintents.org
... we could have subtypes / arbitrary strings
... we have microformats
... there are activity streams
... i don't know that we need to manage it on w3c
jhawkins: for apis we're creating/standardizing
... it's important to control the actual type
... "image" as a type shouldn't be specified by w3
... contact makes sense
... since we need it for the api
... having the documentation at the same place is useful
... i recant for certain explicit cases
darobin: this is for w3 WGs
... not for everyone
... if w3c manages all types, then we don't need the long types
<jhawkins> http://w3.org/intent/share
jhawkins: that works for me too
dsr: there may be some pushback
<jhawkins> http://intents.w3.org/share -- perhaps
darobin: one of the things that came up
... we have actions using webintents.org
... we could just use webintents.org and make it policy
jhawkins: there was concern about hosting+ownership of the domain
... which we could relinquish
darobin: there is an ownership issue
fjh: and also branding
jhawkins: i don't think breaking existing deployments is a big concern
... i think it's ok to change it ONCE and never again
Paul_Kinlan: it's not like we're breaking apps, just reducing discovery
jhawkins: it's just string matching
Paul_Kinlan: i agree we should push it
... the ecosystem is small enough to be able to do it
richt: i know this was feedback on WhatWG
... how do actions resolve?
<richt> how do Web Intent actions resolve? e.g. "//w3.org:80/ns/intent?foo#image"? Or, a simpler more probable example: if the action is defined as "http://w3.org/ns/intent#image" and in my web app I use "http://www.w3.org/ns/intent#image" from memory. What happens here?
richt: we've seen this problem w/ XML NS
jhawkins: intents.w3.org
Josh_Soref: intent.w3.org v. intents.w3.org is this same risk problem
jhawkins: this avoids the w3 / www thing
Josh_Soref: this doesn't solve https: / http: problem
darobin: it's http:
richt: that's proved very bad in the past
... what about a trailing / ?
darobin: when you get it wrong, nothing happens, you immediately know your code is broken
Josh_Soref: we should make failures clear and obvious
richt: why not use wi:foo ?
Josh_Soref: we tried that w/ widget: it failed
Paul_Kinlan: the goal was discoverability
<richt> WI:foo does not have the ambiguity of URLs
Paul_Kinlan: android uses reverse dns
... they do have shortened prefixes
<richt> WI: itself could resolve to a well-defined URL.
Paul_Kinlan: we had a short-form in the spec
... it was a convenience thing
... we got pushback from WebApps or WhatWG
... it was in our initial vision
... i was talking about a property in the Intent object
... which maps back to the string
jhawkins: sounds like we're solving the wrong problem
... it sounds like a lot of hand-waiving
richt: you could have a http://intent.w3.org:80/share
... it resolves, people may expect it works
... or http://intent.w3.org/share/
... you'll end up w/ half of the developers writing one way
Josh_Soref: failure , three examples with implementations, with different action URLs, will get separate pick lists, problem when people copy source from others
jhawkins: i'm going to put $1000 saying that this problem won't happen
darobin: to be clear, it isn't ok for the problem to be created by people in this room
<darobin> close action-549
<trackbot> ACTION-549 Prepare CfC to publish FPWD of Proximity API closed
Josh_Soref: we could ask w3 to force trailing slashes to 404
fjh: richt was asking about forcing resolvability
Josh_Soref: resolving and forcing was a disaster for RSS
... each time netscape.com was rearranged because it was bought out
... half the RSS readers in the world broke because they relied on that NS document which 404d
<richt> So I will potentially have 3 services for http://intent.w3.org:80/share, 4 services for http://intent.w3.org/share, 8 services for http://intent.w3.org/share/
<richt> ...and I'll take James's $1000 :)
Josh_Soref: richt and intents. :)
dsr: it seems like a job for W3 to be responsible to fail with a useful warning for <https> and </>
<dsr> (resolving the w3.org URI for an intent should indicate the registered string even if uri variants resolve ok)
darobin: who wants plural?
[ 6 ]
darobin: who wants singular?
[ 3 ]
<darobin> PROPOSED RESOLUTION: template URI assignment for intents is http://intents.w3.org/*
<richt> my vote was, either works for me but the ambiguity has been lodged in my mind when I write a web app and need to recall it in the future from memory :)
<fjh> proposed RESOLUTION: template URI assignment for intents is http://intents.w3.org/* where * is action or type
RESOLUTION: template URI assignment for intents-actions is http://intents.w3.org/*
<darobin> as noted above, intents.w3.org should be as strict in its resolution of stuff as possible
[ Lunch for 1 hour ]
<richt> lunch with an s or not.
fjh: we're thinking about going to the border Cafe
... how many people are interested?
[ 15 hands ]
fjh: let's say 6pm
<Paul_Kinlan> Paul Kinlan on gvoice
jhawkins: mounir / sicking aren't here
... we wrote up an analysis of their api
... they're closer to our api than we thought
<jhawkins> https://wiki.mozilla.org/WebAPI/WebActivities
jhawkins: the namespace on actions is different
... they use just the name "pick", "share", "edit"
... whereas we use intents.w3.org/pick ...
... they're using an event
... so you can't have the intent payload available onload
... we've reached an agreement that there should be an Intent event
... for delayed delivery
fjh: i don't think that has been incorporated in the spec yet
jhawkins: that's an action we need to have/do
<fjh> ACTION: jhawkins to add event for on load to webintents spec [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action03]
<trackbot> Sorry, couldn't find user - jhawkins
<fjh> ACTION: jhawkins to add event for on load to webintents spec [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action04]
<trackbot> Sorry, couldn't find user - jhawkins
jhawkins: activities uses a DOM Request
<fjh> ok need to do this offline
<nwidell> https://developer.mozilla.org/en/DOM/DOMRequest
<jhawkins> "A DOMRequest object represents an ongoing operation; it provides callbacks that are called when the operation completes…"
<jhawkins> it is essentially a Future
<fjh> ACTION-550?
<trackbot> ACTION-550 -- James Hawkins to add event for on load to webintents spec -- due 2012-07-17 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/550
jhawkins: Intents have a way for pages to declaratively register for the Intent without requiring a manifest
... Activities don't
... There is a way to programmatically register, but that's a different area...
... For imperative registration, Activities has registerActivityHandler
... Intents currently doesn't have imperative registration
richt: I could dynamically add an intent tag to the page, right?
jhawkins: yes
... do i need something in the spec to handle dynamic insertion of <intent> tags?
Josh_Soref: yes
... you definitely need to check for that, because it's often the case that it doesn't naturally happen
richt: if i change the properties of an <intent> tag, via JS, what's the intended result?
darobin: it might be that <intent> should handle this the same way <script> does
... insertion is honored, but mutation/removal is effectively ignored
<fjh> ACTION-551?
<trackbot> ACTION-551 -- James Hawkins to share proposal on list to handle dynamic insertion/removal etc of <intent> tags -- due 2012-07-17 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/551
darobin: wrt. side-effects
<darobin> ACTION: Robin to send some spec text for the way that extras work [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action05]
<trackbot> Created ACTION-552 - Send some spec text for the way that extras work [on Robin Berjon - due 2012-07-17].
jhawkins: for delivery, Activities has setMessageHandler
... and Intents has window.intent (and the Intent Event)
<fjh> ACTION: James Hawkins to see this action [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action06]
<trackbot> Sorry, amibiguous username (more than one match) - James
<trackbot> Try using a different identifier, such as family name or username (eg. jhawkins2, jsalsman)
jhawkins: disposition is the same for both
... and return mechanism is the same
... activities has postError, intents has postFailure
... but that's the only difference
... those are the differences/similarities we've identified
... even though we've raised a lot of differences, they're all small
richt: when WebActivities made it to the whatwg list
... they raised UCs that you guys weren't raising
... what happened there?
... why are they saying different UCs?
jhawkins: i know we talked about that
... we didn't write about it in our analysis
... that reminds me of another thing
... their list of activities seemed to be fixed
... i'm not sure if that's still the case
fjh: why was there so much wind on the list?
darobin: i think it boils down about a few things
... one is a lot of people talked about things they /could/ do with Intents
<Cathy> s/was their so/was there so/
darobin: and mozilla thought they were core to the spec
... but that comes from not reading the spec
jhawkins: it turns out their spec doesn't have a fixed limit of actions
Paul_Kinlan: their spec encourages URLs for non default types
richt: we shouldn't encourage it, but we should allow it
jhawkins: reason for URL is so that documentation can be found at URL - expectation and practice
... we think that the documentation is more important than the namespacing itself
... there are questions we should post to them
... it's unclear if setMessageHandler supports multiple activities
... it's unclear if a user can pick a particular service
... is there a notion of a picker ui?
... there were two statements saying "web activities isn't a discovery api" "web activities isn't a communications api"
darobin: it isn't, but nor is Web Intents
Paul_Kinlan: i believe this was from the stale webintents.org/discover
... because that was documented there
jhawkins: sounds good
darobin: sounds good
fjh: is that stale document still around?
Paul_Kinlan: yes
... i can delete it
Josh_Soref: please make it 410
Paul_Kinlan: i can't do that, but i will delete it in a few minutes
jhawkins: what can we do to go forward without ruffling feathers?
fjh: didn't greg incorporate some feedback using language from web activities?
... send a message on web intents suggesting we're done
Josh_Soref: can we have Paul_Kinlan send a message about having deleted the misleading webintents.org/discover
... check with greg to see if we incorporated something from activities
jhawkins: Activities start with creating a DOMRequest
... which is roughly a Promise
darobin: it depends on whether you have 2 callbacks
<fjh> callbacks versus objects with event handlers
darobin: or are going to start having progress and things
... in which case you want to be able to hang things off of
<darobin> http://scriptlib-cg.github.com/api-design-cookbook/#specifying-callbacks
richt: web activities could benefit from a lot of the things we've discussed about web intents
... and it should benefit from within the web intents framework
... we should have one of the mozilla guys coming onboard as an editor
fjh: let's start with an email
jhawkins: i'll write one
... one of our issues with Web Activities is that the api relies on 2 apis not in the system
... System Message Handler and DOMRequest
jhawkins: we should move to bugzilla
<jhawkins> fjh: https://www.w3.org/Bugs/Public/enter_bug.cgi?product=Web%20Intents
fjh: can we dispense with those issues?
<fjh> http://www.w3.org/2009/dap/wiki/WebIntent_Issues
<fjh> inline disposition needed and if so is SSL required for it
<fjh> rational is need for uniform security of all parts of client page, e.g. if client page protected by SSL then also inlined content...
Josh_Soref: this came up @CoreMob two weeks ago
jhawkins: i'm not opposed to this
<fjh> ACTION: fjh to summarize issue and rationale regarding SSL for inlined webintents content [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action07]
<trackbot> Created ACTION-553 - Summarize issue and rationale regarding SSL for inlined webintents content [on Frederick Hirsch - due 2012-07-17].
<Paul_Kinlan> webintents.org/discover now 410 Gone's and reference is removed from webintents.org/
jhawkins: but it'd be helpful if someone came up with an example
... how is it different if it is in a new tab
... have todo item for showing status for items including inline
Josh_Soref: once there is a security loss one cannot get back
fjh: need the concept of a "secure page"
richt: http and https would be treated as different origins
... same origin policy
jhawkins: need to gather info so we can make an informed decision
... issue event on Intent load (performance issue related to blocking)
<richt> fyi, postMessage spec says "if the targetOrigin argument is an absolute URL, and the Document of the Window object on which the method was invoked does not have the same origin as targetOrigin, then abort these steps silently" http://www.w3.org/TR/webmessaging/#dom-window-postmessage
<richt> (before passing the message to the target origin)
<fjh> I have updated the DAP WebIntents issue wiki to point to Bugzilla, http://www.w3.org/2009/dap/wiki/WebIntent_Issues
<richt> so we should adopt a similar approach with Web Intents wrt http/https message passing only
<Paul_Kinlan> can we post the contact intent demo to IRC?
<fjh> Contacts-Intent Service (demo)
[ Josh_Soref demos installing intent ]
[ Josh_Soref demos breaking Chrome by closing the provider without confirming/canceling ]
jhawkins: perhaps we should post an error code
[ currently it posts an error of <null> ]
richt: i like it
... we don't usually target non browser vendors
Josh_Soref: here browsers will probably implement contacts for devices, but they'll be in the minority
<richt> so the target is primarily web developers directly. I expect most developers don't understand and shouldn't need to learn WebIDL so a different form of documentation might ultimately be more helpful.
<richt> ...for the Contacts Intent
Josh_Soref: tantek sent feedback on contacts a while ago complaining about lack of alignment to vCard 4
fjh: can we agree to publish an updated draft once darobin finishes editing his draft
... i think we should publish an updated WD
RESOLUTION: Publish Pick-Contacts-Intent as WD with same shortname ("contacts-api")
<fjh> jungkee gives demo of Pick Media
<fjh> draft -> https://dvcs.w3.org/hg/dap/raw-file/29d23bcac5ee/gallery/Overview.html
richt: what about local intent, is this an issue
... how are you handling files?
Jungkee: i'm using URLs, either real or data:
darobin: the problem w/ URLs/Blobs is that the server will have to download the data for 200 videos
... it'd be useful to have blobs that are lazy pointers to urls
<fjh> lazy blob
Jungkee: so when the blob tries to trigger the blob, it then triggers the xhr?
darobin: right
<darobin> ACTION: Robin to make a proposal for LazyBlob [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action08]
<trackbot> Created ACTION-554 - Make a proposal for LazyBlob [on Robin Berjon - due 2012-07-17].
Jungkee: i know that there's a search api that this WG has considered for contacts
... i propose simple string based searching
... also, for metadata, having to define them ...
... i picked Media metadata based on flickr/etc. as well as Media Annotations
Wonsuk: we looked at EXIF/MPEG-7
richt: we should start with a smaller list
Jungkee: the core set from Media Annotation is 27 properties
... i'd like to drop some of them
Paul_Kinlan: one of the thing the Chrome Apps team as part of Sys Apps Work
... is to take a File reference via Web Intents
... so you can get access to raw file itself
... instead of having to pass around Blobs
... it's special cased
... one you get a special cased URL, you can use XHR
... but you get cross origin issues
<Zakim> fjh, you wanted to discuss roadbump and robin issue, break time
Paul_Kinlan: lazy blob sounds cool
fjh: sounds like the speed bump discussion is somewhat similar
darobin: it isn't quite the same
fjh: it sounds similar
[ Break ]
fjh: we should publish a new draft
RESOLUTION: We will publish a WD of the Pick-Media Intent with the same short name as Gallery ("Gallery")
jhawkins: how did Gallery appear in the Charter?
Josh_Soref: Gallery/Contacts were initially requested
... based on the assumption that devices had valuable local stores
fjh: we assume that webintents can be used for both remote and local services
... but some of us looked at the world and decided that web stores were more likely to be of value
... so we wanted apis that could handle both
richt: e.g. Unified Addressbook
... not specifying the source of contacts, but combining local/remote data
Josh_Soref: and thus they were added to the DAP charter ages ago
... and are relevant with/without Intents
... Intents is just the way we decided would be best to address them
<fjh> list of DAP deliverables in charter -> http://www.w3.org/2011/07/DeviceAPICharter#deliverables
<darobin> Proposed SysApps WG Charter
jhawkins: what is the relationship between DAP and Sys Apps?
<vandebo> The main gallery author (sorry, forget his name) has been focusing the Gallery proposal on the online case, and has suggested deferring the local media case to the sys apps group. This seems counter to the groups intent
<darobin> vandebo, that's not an entirely correct characterisation
fjh: that's not true
<darobin> vandebo, DAP's Gallery is both for local and online, but it is limited in a number of things (e.g. write-back)
fjh: sys apps is focusing on local cases requiring local permissions and more underlying apis to the platform
<darobin> vandebo, whereas what's in SysApps is far more advanced and complex, and has security implications beyond what is usually acceptable in a browser
<darobin> vandebo, the same applies to contacts and a few other things
richt: sys apps is "throwing the kitchen sink at things"
... "let's give away the farm"
darobin: that's a decision for Sys Apps to make (after it forms )
fjh: the focus on DAP is for simple applications that can use remote or local resources, so these re relevant to DAP. Sysapps will have more detail for trusted environments and may do similar work, but this should not preclude DAP from doing its work
<vandebo> darobin: ok. I was under the the impression that what I said was accurate from the various list dicussions, but I'll admit that it's not entirely clear. It seems that's not the intention, so my question is moot.
dsr: this group is focusing on cases where the application you visit aren't trusted up front
richt: i know this is sys apps, and sys apps doesn't exist yet
... but if they want what they make to be available in browsers
... they'll have to tread carefully
<fjh> discussion of what SysApps should do should not be the discussion of the DAP WG.
dsr: we have two charters
... for sys apps, we did a poll to find out what people are willing to implement
... what they're willing to edit
... what they're willing to write test cases for
... the charter is split into two phases
... the first phase is primarily working on Security Model and some test apis
... that aren't controversial
... and then there was a problem that the list of apis was too long for a group to work on in its allocated time
... if the group is successful, it could then take in more items (rechartering)
... i'm now waiting for W3C Management (W3M) to approve the charter to enter W3 Review
<dsr> Proposed SysApps WG Charter
<dsr> Proposed NFC WG Charter
fjh: So we have a charter and chairs listed.
<vandebo> that's me, sorry I don't know the protocol
dsr: next step is for the charter to be approved.
... the mission statement for sys apps has been 'wobbly'.
... is going to get darobin or fjh to help with that.
fjh: send it over to darobin and I and we'll take a look at it
dsr: hope to get AC approval to start Sys Apps starting next week.
jhawkins: so what is the overlap between DAP and Sys Apps?
darobin: the primary overlap is around data formats.
... Presumably Sys Apps will have a 'deeper' API than a similar DAP API but presumably it will use the same format.
jhawkins: It sounds like who you're targeting for implementation is the difference
fjh: correct
... we don't need to deep dive now. The Sys Apps working group will need to tackle these issues early on.
... In theory the DAP API should be used wherever possible...depending on the requirements,
darobin: there is likely to be enough of an overlap in membership so that coordination between Sys Apps and DAP will not be a problem.
... a lot of the people in this room are likely to also be involved in Sys Apps.
... would be useful if, at the beginning of Sys Apps, someone retrace the history of DAP so they don't make the same mistakes.
<richt> Proposed NFC WG Charter
dsr: At a similar point to Sys Apps. Still looking for the chairs for that group.
... believe we can go to AC review without having chairs in place.
gmandyam: Would like a little more detail on Phase 1/2 in Sys Apps.
<fjh> group discussed potential collaboration/overlap with Sys Apps
<fjh> Heads up on progression of charters and AC review plans for these potential WGs
gmandyam: PhoneGap specifically refer to existing APIs. Are you planning to follow that so there's no unnecessary replication of APIs?
dsr: can't speak for the group directly since it hasn't formed yet.
... the general feeling at the moment though seems to be where APIs are 'good enough' already they will be used.
gmandyam: what is difficult at this point is that multiple APIs already exist and it's going to be difficult to work around that.
dsr: those discussion are still to take place since the group hasn't been formed yet.
gmandyam: ok, thanks.
darobin: several things we can talk about here.
<darobin> using-testharness.js
darobin: specifically want to bring up two things.
... 1. The tutorial for using testharness.js (link provided above by darobin)
... we are getting a lot of input tests that are using the framework slightly wrong
... so hopefully this will help people.
<darobin> W3C Test Framework
darobin: 2. W3C Test Framework
... lists all the test suites that the tool knows about.
... allows you to import a test suite from a manifest file (manifests can be generated from a small tool).
... anyone on the web can then run a test suite directly from this framework.
... makes it possible for the web site to gather test results in a distributed way from users.
... so the idea is to group everything, gather lots of data and analyse subtle differences in implementations.
<darobin> JSON for Element Traversal test cases
<darobin> Test Framework JSON API
darobin: Test Framework API also available (link on line above by darobin)
... so you can hook in to the tool from your own code/systems
<Zakim> fjh, you wanted to ask if test app suite requires writing spec in particular manner
fjh: is this stuff seperate from the work that Dom and Marcos did on how to markup tests.
<richt> Marcos and Dom's test methodology spec
darobin: what we don't have yet is consensus on a single way to markup a spec with test assertions.
... there are two testing groups in W3C
<darobin> W3C Web Testing Activity
darobin: I encourage you to join both of these groups
<darobin> WebDriver API specification
<fjh> darobin: this wg is creating driver for automating browser testing, screen testing etc
<fjh> rberjon: interest group looking at overall W3C testing infrastructure, including test framework etc
<darobin> Web Testing Interest Group
dsr: when do these groups expire?
darobin: end of 2013.
... for Web Testing Interest Group.
<Zakim> dsr, you wanted to note that there seems to be some bugs in how results are reported on some platforms
dsr: Playing around with Vibration test suite yesterday. A couple of minor things came up.
... the way it reports the platform is a bit strange.
darobin: it gets it from the platform so nothing we can do.
dsr: I was expecting the device to vibrate on some tests.
... it didn't.
darobin: that seems like it might be a failure.
dsr: it was marked as passed.
darobin: will look in to it.
<Zakim> fjh, you wanted to ask where to look for status of battery, vibration testing
dsr: We're publishing test results without the UA vendors permission. Any problems with that?
darobin: we don't have any problem with that.
fjh: this is all generated from public information
Josh_Soref: IE in pre-release says that you are not authorized to post write-ups or reports on those products.
... that's not really a bad thing for a company providing a beta product.
... they have occasionally gone after people for going against these T&Cs.
darobin: Future W3C Test Framework feature: If you have data you don't want to include then you don't include it
fjh: Anonymizing/aggregrating the data is a way to avoid these issues.
<Zakim> fjh, you wanted to mention existing practice
darobin: in practice this shouldn't be an issue since we don't generally have access to internal builds.
Josh_Soref: Where do bug reports go for the W3C Test Framework?
<darobin> Report a bug against W3C Test Framework in Bugzilla
darobin: Any more q's on testing/interop?
jhawkins: still need help with testing for web intents
fjh: maybe we can talk about that tomorrow.
[fjh goes through the proposed agenda for tomorrow]
fjh: Not sure how much we'll have on Thursday but we'll have to see.
... tomorrow's agenda is: UPnP/Discovery, Web Intents (testing), [lunch], ...Web Intents, Network Information API.
... Plan to start at 9:30 tomorrow morning.
... Any concerns about the agenda tomorrow?
<fjh> Other topics to follow will be media capture review, network information, sensors
fjh: Will be doing a UPnP demo during the UPnP session.
... We have a dinner at 6pm tonight.
... at Border Cafe, Middlesex Tpk.
... meeting is in recess.
trackbot, end meeting