- From: Paul Kinlan <paulkinlan@google.com>
- Date: Tue, 21 Feb 2012 15:34:08 +0000
- To: Dave Raggett <dsr@w3.org>
- Cc: "public-web-intents@w3.org" <public-web-intents@w3.org>
- Message-ID: <CADGdg3ADZFo++5b2DvXNAMjXty0Jd8pZgdJaHNrtqYuxd+07ow@mail.gmail.com>
Hi Dave, CIL. On Tue, Feb 21, 2012 at 2:56 PM, Dave Raggett <dsr@w3.org> wrote: > On 21/02/12 13:48, Paul Kinlan wrote: > >> What is responsible for selecting the photo to share? > >> > >> a. the current web page that invokes the share intent > >> b. the user selected photo sharing service > >> > >> As far as I can tell, the Google proposal is for (b) as I haven't found > >> any mention of the API for passing a photo to a photo sharing site. > > > > It is (a) - The current page passes the data to the photo sharing > > service in the intent object. > > Hi Paul, > > Thanks for the swift answer. > > I believe that you are saying that the intent object is cloned and > passed in memory to the browser context for the service page. In other > words, the object is passed locally, and not via the website's server. > Is this also the same in reverse when the service page sends a response > to the requesting page? You mention the structured structured clone > algorithm - can you please point me to the definition you are using? > Yes it is all managed locally. Structured Clone - http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data- with support for Transferable objects. > > I am having a little difficultly finding all the details. Where is the > intent object formally defined? I was expecting something along the > lines of the definitions in the HTML5 spec. > I believe the intent objects, definition will reside in this spec, to be merged later once the task force returns its proposal. James Hawkins can shed more light on this than I can. The latest version of the spec if here: http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html > Is the data transferred always identified by a MIME type? If so, what > type do you use when the data is actually a URL? text/url seems > plausible, but see http://filext.com/file-extension/URL for a list of > alternatives. > We have always been using text/uri-list when it is a physical URL. > How is the intent object received by the service page? I think it is > passed as the argument to the onintent method on document.body, or is > that just Ian Hickson's proposal? > That was Ian's proposal, the current implementation (shim and in chrome) populates window.intent when the UA knows the page still supports the action, so in Chromes manifest case, it will be ready very early in the page lifecycle, if it was detecting the tag, only when the tag is parsed. (This currently is not in the spec I believe) Likewise how does the service page send the response? Ian suggests > using postMessage on the port obtained from the onintent event. > window.intent.postResult( .... data ..... ); We don't want to deal with ports and unless you absolutely have to, most of the intents are simple request/response and as such there is no need to pass a port in, and then communicate over it (because once you have a channel with potentially 1..n messages it starts to get complex quickly). So in the case of "share" you just pass the data you want to share, and that is it. > > Is the service page expected to close itself, whether it is a new > window, a new tab or inlined in an iframe in the original page? > The shim you have to close yourself, the native implementation should be closed automatically once the data is sent. > > I wasn't able to find the details on webintents.org, but I could have > easily have missed something. > It should be in the spec, if it is not then a bug needs to be raised against it. > > There is nothing like doing an implementation to throw up questions > about proposals! :-) > Cool - let me know if I can help. > > Many thanks. > > -- > Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett > -- Paul Kinlan Developer Advocate @ Google for Chrome and HTML5 G+: http://plus.ly/paul.kinlan t: +447730517944 tw: @Paul_Kinlan LinkedIn: http://uk.linkedin.com/in/paulkinlan Blog: http://paul.kinlan.me Skype: paul.kinlan
Received on Tuesday, 21 February 2012 15:34:43 UTC