Re: A simpler, webbier approach to Web Intents?

On Thu, Feb 16, 2012 at 6:38 PM, John J Barton
<johnjbarton@johnjbarton.com> wrote:
> On Thu, Feb 16, 2012 at 5:56 PM, Greg Billock <gbillock@google.com> wrote:
>> On Thu, Feb 16, 2012 at 2:15 PM, John J Barton
>> <johnjbarton@johnjbarton.com> wrote:
>>>> We explicitly support passing any structured-cloneable type in intents
>>>> payload. This includes Blobs and other file-ish types, ports, and
>>>> esoterica not yet invented. :-)
>>>
>>> Then how do you have an advantage over postMessage() over MessageChannel?
>>
>> I was just clarifying that we do not intend to allow passing of a
>> narrower range of types than would be possible with postMessage in
>> page-to-page situations.
>
> On the one hand you claim that web-intents is better because it does
> not allow specifying complex communications. Then it's better because
> it can. I'm sure it's better, but being clear on why is important.
>
> So: In the communications layer, web-intents makes MIME data
> transmission simple but allows any structured-cloneable types,
> including those types of messages sent over postMessage.

:-) The mechanics are defined in the API, but I think the thing to
call out here is that there's a) the full ability to pass structured
clones, and b) for many situations, including the ones we think will
be the most popular, the requirement is to fully specify the request
before invocation, which is has good interoperability characteristics.

The big question about RPC vs. messaging channel, then, is which to
use when. If you think that most interactions will be complex and
require extensive coordination, then it would make sense to use a
messaging channel substrate and make RPC-style interaction a special
case of that. If you think that most interactions will be fairly
simple, then it is more natural to use an RPC-style interaction, and,
where necessary, use that to establish a messaging channel.

That's what we think will be the case: the lion's share of use will be
of the "share this link" or "save this file" variety, not only
RPC-friendly, but often fire-and-forget-compatible. Our intuition is
that setting up a messaging channel for those cases is overkill, as
well as being harder to integrate with browser/system events and
services.

An intuition pump here is to go back to the use cases: they are by and
large for loosely connecting clients and services that know very
little about each other. The more complex the protocol between them,
the more they need to know about each other. The less they are
required to know about each other the better.

>
> Why wouldn't I race James to create WorldsMostAwesomeWebIntents page
> full of <intent> tags?
> Won't people be motivated to create ad supported lists? Won't users be
> bombarded with <intent> pages?
> I guess these are problems you'd love to have.

:-) We're attempting to think ahead on that front, but yes, it'd be
great to get enough adoption to be worried about noise instead of
silence.

>> You can try this out in the current Chrome beta and developer channel,
>> if you're interested in seeing how we think this will work.
>
> I've seen the demo live. It's very cool; that's is why I posted my questions.
>
>>
>> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-February/034881.html
>
> Is this the correct reference? It seems to be some completely
> different and uninteresting topic.

The part I was referencing is towards the very end.

> Thanks for your answers. You're convincing.
>
> jjb

Received on Friday, 17 February 2012 17:14:46 UTC