Web Intents minutes 9/7/2011

[Sheridan Rawlins]

Please keep in mind that these notes are raw (just trying to type as fast as people spoke), and my laptop lost network for some time, so I kept some notes in raw form and inserted them afterwards; I hope they make sense.

---

Web Intents

9/7/2011

Attendees: Mike Hanson, Ben Adida, Tyler Close, Paul Kinlan, Darin Fisher, Sheridan Rawlins, Greg Billock, James Hawkins

Proposed Agenda

• W3C
• Prototypes
• Service disposition

Agreements

Followup

• Tyler: Investigate whether registerProtocolHandler could do everything needed - write up and code something against the use cases on Paul’s site.
• Get involved in RPH discussion: new calls?
• Darin: last-ditch effort to get our work into conversation on AppsWG.
• Ben: investigate expediting creation of XG or WG on W3C
• James: approach Ian Hixie about discussing on WhatWG.

Next steps:

• standards:
• XG how fast? (moz: ben)
• WG Webapps (goog: james, darin), WhatWG
• RPH:
• Use-case review (goog: tyler)
• Affiliate:
• need to have

Discussion

• W3C
• Darin: propose to WhatWG; talk to Ian Hixie about how to post and how to host spec on WhatWG.
• Darin: Point of WhatWG is that WWW process is just that; process.
• Ben: what is goal of standardization?
• Darin: get on the path to standardization.
• Mike: are there reasons why we need to do this?
• Darin: Yes, to get this landed in WebKit, it is evidence/artifact showing commitment towards getting standardized and tempering possible webkit concerns.
• Mike: is discussion on WhatWG enough to satisfy concerns?
• Darin: I think so - it is known that a lot of things get discussed there first and then move to more formal standardization - it is a reasonable “fast pass” to getting things moving.
• James: spoke to apps WG, who said that they would need to recharter to include us in the mix.
• Ben: expect that from full-fledged WG to limit their scope.
• Ben: reopening discussion on XG
• James: takes 3 months - too long.
• Ben: is 3 months too long?
• James: yes - to unblock webkit commits.
• Ben: what about DAP? non-starter because we should be on the same page as Apple.
• Tyler: for unsticking - consider the registerProtocolHandler and web+
• Can override your own schemes and/or whitelist.
• Ben: Does using or extending RPH make this less difficult?
• Ben: if we find new use cases that aren’t handled, then we’re back to square one about standardizing again.
• Tyler: what use cases do startActivity handle that registerProtocolHandler not handle?
• How do you pass stuff back? Paul: there’s a limit on what/how much data can be returned in the location.
• Ben: I think we’re in agreement that we want something that’s easy to understand - not a HUGE change to the web for people to stomach.
• Darin: One nice thing about RPH is that this may work on all browsers today;  browsers could be smarter and do a picker but you wouldn’t get the picker (firefox has the picker already).
• You could register protocol handlers for anything on the system.  May need to do on the console.
• Darin: intriguing idea - may not require anything but UA changes.
• Using window.open gives you a window object which you can then postMessage on.
• Thought about using intent:// scheme and flattening URL
• Mike: do we lose the ability to do structured clones?
• Not if we use postMessage to send the data.
• James: intercept window.open call and mediate call to picker
• James: when do you know when you can send postMessage?
• Darin: yeah, that is one of the biggest issues - when to send the data?
• Couldn’t get the right event (ready state) when it’s another domain.
• Tyler: May not work on window.open (events may only work on iframes; not windows).
• Ben: Don’t want to discount Tyler’s idea, but everything is dependent upon an existing protocol - it sets the ceiling for what we can do based upon what RPH can do.
• Darin: maybe there could be other ways of opening a window.
• Ben: I hear this and I think this is really awesome as an implementation strategy, but not so much on a standardization strategy.
• Paul: From adoption point of view, all developers would have to think about all different serialization strategies.
• James: how is the usability of this solution - one of the big goals was to make this very usable for developers (client/service), users, etc.
• Darin: this approach would lead us down to having different schemes for each intent.
• Darin: Could suggest extending RPH to have filtering mechanism.
• Darin: Share handler provided these filters pass.
• Darin: if we had to add UI for handling intents & RPH, how would users know the difference?
• James: WebIntents could take over the place of RPH eventually.
• Darin: could RPH generate an intent when it doesn’t have a registered handler?
• Darin: would need to do backward compatibility in some way.
• Ben: I think what Tyler’s saying is “let’s punt on standardization because it’s messy” - I don’t think it’s possible to fully punt based on initiation. Not having intent fails pretty badly.
• Tyler: isRegistered may be able to allow clients to do something sensible.
• Mike: isRegistered is a way of fingerprinting...
• Ben: window.open - would the UA intercept and not open the window and/or bring up an open?
• Mike: Shouldn’t be able to silently probe 500 protocols.
• Mike: There’s a lot of discussion on extending registerProtocolHandler.
• Darin: Sounds like we should inject ourselves into the conversation.
• James: code paths of WI and RPH are very similar.
• Mike: worry that the web+ idea is going in the opposite direction from where we’re going?
• Darin: Abartz responded to some DAP discussion with “why don’t you just use a URL?”
• Ben: RPH is the intent or activity of sharing the image - within it there could be multiple message - that’s where the handlers could come in.  Kind of comes back to looking like Introducer inasmuch as you end up with a postMessage pipe.
• Tyler: with RPH, you could be able to handle simple intents easily - fire & forget without needing a postMessage.
• Darin: URL gets stamped into another url that provider registers for.  For every RPH you must register the data scheme.
• Paul: Thought that advanced use cases for intents could be documented & implemented.
• Ben: some really compelling stuff here. But makes it challenging to make the vision as the trusted UA for more than just the picker.  If we use window.open, then shouldn’t the end result be an open window (and not the disposition inline, etc).
• Paul: what about privacy concerns?
• Tyler: could provide the origin.
• Tyler: if provider is first one to
• Mike: Could we be on to a list of feature requests to RPH to bridge the gap?
• Darin: Wouldn’t be surprised if other folks could say “why aren’t you just using RPH?”
• Mike: it does ~78% of work (doesn’t do blinding, picking, security, etc).
• Ben: RPH and Introducer are just hooking up a message channel.
• Tyler: there could be fire-n-forget through URL.
• Paul: If you want to provide basic feedback of whether you’ve successfully performed an action.  May need to have a return for everything even fire-n-forget.
• Darin: RPH still need to educate developers on how to use postMessage.
• Paul: Didn’t want developers to have to worry about messages coming through.  Chatty/permanent channel seems like 10% of the use-cases.
• James: Intents is a superset of RPH. Intents is a semantic version of RPH.
• Darin: Windows - you could go to the registry and enter chrome for mailto: urls.
• Implementation details
• Greg: we’re doing window.intent as a bound object
• Ben: does that end up not being in webkit and therefore easier to land?
• Darin: no, that isn’t really a consideration.
• Greg: it might even be nicer to have it in webkit for ease of adoption. If we go to a callback-based API, we’d do that.
• Mike: the spec says the UA can do whatever it wants on an RPH registration
• Mike: RPH has support for immediate and deferred data
• Darin: it’s always nice to build on something that exists.
• Ben: I’m willing to help with getting some standards body work done. Knows folks at W3C to help streamline insertion into a WG/XG/CG.
• James: Darin’s going to talk again to W3C about getting into public webapps.
• Ben: that timeline is still good enough? better than XG?
• James: yes - XG is unnecessary extra step when intention is that we would eventually get to a real working group - just need a place to discuss to unstick effort in WebKit before real/formal WG is formed.
• Ben: He can see if he can expedite with W3C creation of XG or WG.  In parallel, we’ll try to get going on the standardization and exploring RPH.
• Ben: what do we need to do with RPH?
• James: Should come up with joint doc between Mozilla / Chrome.
• Darin: lightest weight work would be working with WhatWG - just tell Ian that we’d implement.  
• Mike: Would need to convince Jonas & Rock - who are involved in RPH discussions.  Michael Davidson, Peter Kasting are involved/verbal about it.
• Ben: use cases in next 6th months - what are the biggies: ** Mozilla too. * just Moz. James: want to make sure that we don’t try to enumerate all use-cases because the point is that people can develop new intents without needing us to implement new stuff.
• ** Share: biggest thing.
• James: does the type of sharing always need to be a url?  What about levelling up in a game?
• Edit image: have image on twitpic, want to edit it before sharing.
• Bookmark: want to save for later.
• ** Pick/Get/Put: from cloud or device - type could be “file” meaning file-picker.
• View: more from Android - may want to view in another application.
• Darin: couldn’t this be for types that the browser doesn’t support
• Darin: example fire off gview to view an intranet doc.
• Subscribe / Follow: to Atom/RSS, etc
• Login / Authenticate: for open-auth, e.g. how to pick an oauth provider. list of IDPs.
• James: like the auth action - list of services are the ones you use to log in.
• Ben: must say login with “oauth” and only those providers.
• Paul: maybe filter based on oauth/*
• James: should do the oauth dance; not return a list - reveals too much (fingerprinting...).
• Mike: What about Calendar
• Ben: How ‘bout posting to activity stream?
• * Get Contacts: Paul: what about pick with type of contact/email?
• Ben: are you thinking about device stuff?
• James: mostly broadcast - like a camera is plugged in.
• Greg: in 6 month horizon, we’re mostly focusing on webapp <-> webapp.
• Sheridan: what about the purchase/finance/buy-this case?  Mike: only for “keeping it honest; not first pass use case
• Ben: need to think about how to package/bundle this. think Facebook connect?
• Mike: It would unlock a bunch of APIs for connectivity with a site - say NPR has a facebook connect; you authenticate, and now NPR.com has access to your friends, your contacts, etc.
• Ben: providing a way for people to re-mediate the connections of information would benefit the web.
• Ben: could we bundle connect as showing providers which handle all 4 intents.
• Mike: I want to say use my gmail contacts everywhere and allow completion everywhere without needing to need user interaction.
• Scoping auth for intents - for this session, use this/these providers.  For this profile, for this tab.
• Tyler: say a memory card is inserted with 20 images, do I have to click something for every image to share them?
• James: you should select them, and share once.
• Autocomplete?  James: could be disposition=background and keep-alive.
• Ben: you're saying that you want the API to be one-shot, but there may be workarounds.
• James: if activity repeats, UA can notice patterns and prompt them to choose defaults, rather than making a "channel" (bundling actions dedicated to a site)
• James: one thing against channel/connect - the user loses the ability to consent to every action.
• Ben: RE: bundling. Do you think of one intent to describe one action - or would "connect" take separate messages?
• James: there is a goal to pass a MessageChannel as a data
• message channel perceived as the 10% "long tail".
• Tyler: nobody knows for sure - they're just pulling stats out of.. well, inventing stats :-)
• Ben: share/send use case - let's dig in:
• I'm on a blog, what does that look like.
• http://webintents.org/
• James: Disposition!!!
• inline: shown in picker
• background: tbd - no UI from provider
• new (_blank): new context (window/tab).
• Ben: How set are you on intent tag?
• Paul: search engines, copy/paste code,
• Ben: concerned about adding html elements.  In general it's an iffy area.  We like tying this to a webapp because of the level of ceremony (when you install an app, you give it privileges).  In addition to that, should there be an intent tag.
• Tyler: what are the hot-topics from google-apps
• Onepick cloud-based file picker.
• James: Very interested in using intents
• Ben: is there an intention to have intents integrate with Android - is it a goal or was it just inspiration more than integration?
• James: It would be awesome to have, but it wasn’t a goal.  Depends upon timeline of Android browser, over which we don’t have control over.
• Paul: May want to daisy chain - pick a file from somewhere, edit it, and share somewhere else...
• Mike: if you read about the aspirations of RPH, there’s a lot of talk about talk this share that, repost my blog, etc.  People who originally worked on RPH had this in mind, but it was so general in its goals, that they didn’t crack the developer or UI “nuts”.  Austin.