W3C home > Mailing lists > Public > public-web-intents@w3.org > February 2012

Re: A simpler, webbier approach to Web Intents?

From: Ben Adida <ben@adida.net>
Date: Wed, 15 Feb 2012 19:35:38 -0800
Message-ID: <4F3C798A.4090500@adida.net>
To: public-web-intents@w3.org

Hi folks,

I wanted to follow up on the post I wrote about finding a simpler 
approach to Web Intents [1].

Looking at the latest posts, I see the following from James:

> One of the design goals of Web Intents was to eventually replace the
> functionality of RPH/RCH in a simpler, more intuitive fashion.  This also
> means eventually deprecating those methods to have a consistent API.

I'm confused by this, as it seems to be backwards. Replacing 
functionality in web browsers is quasi-impossible. Shouldn't we, 
instead, be thinking about how to tweak existing functionality to 
encompass new use cases? That seems like a much safer approach.

On my blog, Greg points to a number of long-standing discussions about 
RPH. None of these discussions, as best as I can tell, make a solid 
argument that we have clear use cases that cannot be fulfilled with a 
simpler approach like RPH. Heck, even my arguments from September are 
about overall aesthetics, not very well backed by use cases.

Looking at the FAQ on webintents.org, the following arguments are provided:

> We don't think this goes quite far enough, the protocol handlers have
> no concept of what data will be presented to the launched
> application; what happens when the opened application can't handle
> the data?

First, I'm not entirely convinced that this is a big problem. We might 
want sharing links to be different from sharing images, in which case 
different schemes could be considered.

> how do you send an image to an app?

postMessage some data.

> There is no way to communicate data back to the calling application.

postMessage back to the caller.

Am I missing something? Very little of this seems particularly hard, 
which makes me lean towards using what we already have.


Received on Thursday, 16 February 2012 03:36:04 UTC

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