W3C home > Mailing lists > Public > public-web-intents@w3.org > December 2011

Re: Using webintents to enable HTML+JS plugins

From: Greg Billock <gbillock@google.com>
Date: Tue, 20 Dec 2011 13:57:41 -0800
Message-ID: <CAAxVY9fN=SDqNZQbPi8y4f=sY2JzkFJSmNms4UCdktLKqvH9kw@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:45 UTC