Re: A simpler, webbier approach to Web Intents?

On Wed, Feb 15, 2012 at 7:35 PM, Ben Adida <ben@adida.net> wrote:
>
> 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.

Something we haven't talked about in a while, but which I alluded to
on your blog, is that postMessage already has an established
semantics: it is intended to be used for application-specific
conversations among frames/workers that know each other well, using
messaging defined by the application. Web Intents are quite a bit more
distantly communicating, according to much more tightly-constrained
rules of interoperability.

To bring this to the fore, what happens if you want to handle an
intent on a page that uses postMessage? How do you tell the intents
messages from the non-intents messages? All of a sudden we need some
kind of namespacing on postMessage payloads, or they interfere with
existing applications. Interfering with already-deployed apps isn't
impossible, but it requires an extra level of motivation. There's
already been adjustments to postMessage to make cross-origin messaging
safer. Are we sure all existing and future uses for postMessage will
be compatible with overloading intent delivery onto them? That seems
to me like taking on a significant burden in the future evolution of
postMessage, which seems to me to be doing a good job of doing the
"user-specified actor coordination" thing.


> 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.

One of the main features we hope to achieve with web intents is
extensibility. That is, you don't need to get a new action added to a
whitelist and enabled in browsers to start using it. The web+ prefix
could potentially do this with RPH, but it is having traction trouble
for a reason, and there are all kinds of bad intersections with
super-cookie concerns and the RPH API itself that need careful
thought.

I think the fundamental problem here is that modeling intents as URLs
doesn't fit will. An intent is not uniform. It is user-mediated. An
intent is not a resource. It is a request for action. An intent is not
a location, it is a task. It's possible to map any data onto a url, of
course, but I think at some point that becomes an obstacle to
understanding. What happens on <srcipt src="intent-url"> or
window.location = intent-url? I don't see that telling web developers
that intents are urls is going to be easy to explain, although it is
perhaps a bit easier to implement.

>> 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.
>
> -Ben
>
> [1]
> http://benlog.com/articles/2012/02/09/a-simpler-webbier-approach-to-web-intents-or-activities/
>

Received on Thursday, 16 February 2012 07:04:32 UTC