- From: Greg Billock <gbillock@google.com>
- Date: Tue, 20 Dec 2011 13:57:41 -0800
- To: public-web-intents@w3.org
On Sun, Dec 18, 2011 at 11:23 PM, Dominic Cooney <dominicc@chromium.org> wrote: > On Sat, Dec 17, 2011 at 9:57 AM, Darin Fisher <darin@chromium.org> wrote: >> >> Crazy idea alert! >> >> Assuming we invent an intent to handle a mime type (the View intent), then >> I could imagine >> it opening up the possibility to not only support explicitly started >> activities to handle a >> particular mime type, but also the incidental encountering of mime types >> (<iframe>) or the >> explicit embedding of a plugin to handle a mime type (<embed>/<object>). >> >> Traditionally, browser invoke plugins to handle non-built-in mime types. >> It seems >> WebIntents could enable HTML+JS to be used to do the same. > > > In general I like this idea, since presumably a HTML+JS+etc. "plug-in" can > be sandboxed effectively. We've given some thought to translating unknown content types to Web Intents. It would essentially be like translating RegisterContentHandler type calls to a view intent for that type. There's details to work out in the translation--giving the url to the handler website may not be as nice as passing a Blob, for instance--but conceptually this should be very straightforward. The bigger problem to work out is where to display the UI surface. Should it play in another window? In the picker? In an inline iframe within the <embed> bounds? We've resisted that kind of embed so far, but perhaps this is a compelling enough use case to take another look at that. Certainly for things like <a href="resume.doc">Resume</a> which returns an application/msword it'd be nice to be able to have Office Live be able to register for the corresponding intent and edit the doc in another window when the link is clicked. >> I'm sure there are plenty >> of details to work out about how an <embed> tag would magically have HTML >> content >> loaded beneath it, etc. > > > I guess this part is outside the scope of Intents. > > In places the difference between Intents and plug-ins might work against > you: The multiple-provider mechanism in Intents is different to traditional > plug-ins, where there is one provider for a given MIME type. <embed> etc. > are not necessarily in response to a user action—is the thinking that intent > initiation should be in response to a user gesture? For initiation of intents by web apps, yes. The spec doesn't preclude the user agent from launching an intent based on other considerations, though. I'm not sure whether maintaining the user gesture idiom in such cases is a worthwhile goal or not. I suspect not, but the UA has the option to maintain it by displaying a UA-specific surface in an embed area which asks the user to click to choose a handler (a la broken puzzle piece for unsupported embeds currently, which can prompt for an install). >> There's also details about how the "document data stream" would be >> surfaced to the content. >> One could imagine using Blob or some other streaming mechanism. > > > Is the idea here that the Blob is virtualized over the stream? Blobs are serializable, so the UA can provide a Blob implementation to the service page, yes. (This is actually a pretty awesome way to do some kinds of sophisticated intent processing; it works out of the box in our Chrome prototype code.) > >> >> Crazy idea? >> >> -Darin > >
Received on Tuesday, 20 December 2011 21:58:17 UTC