Re: A simpler, webbier approach to Web Intents?

On Fri, Feb 17, 2012 at 9:14 AM, Greg Billock <gbillock@google.com> wrote:
> 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.

I totally don't understand your terminology here. RPC means remote
procedure call:
http://en.wikipedia.org/wiki/Remote_procedure_call
RPC is a complex, bi-directional communications simulating full
function call semantics.

Does Web-intents really plan to support RPC?

postMessage can support RPC, but I don't think web intents can. But
more to the point, I don't think anyone wants RPC! We've discovered
the hard way over many years that full RPC is too complex and prone to
failure.

The messaging paradigm that postMessage devs focus on might be called
"readdressable request response".  A request provides either the data
we seek or an address (object name) where we can invoke remote
actions. The action-invocation is request/response.  The resulting
call chain is much shallower than RPC. It's much more like a web page
GET followed by XHR: the GET provides addresses  for subsequent XHR
requests.

For a concrete example, look at the Orion Web IDE.
http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/Architecture
They have client-server operations that are REST api based and a
cross-domain  iframe plugin system using postMessage.

I think the distance between web-intents and the reality of
postMessage interaction is smaller than you think. It's a nice
continuum not an either / or.

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

Yes, I agree, if you count number of uses at the beginning. But I
think your technology can also support more sophisticated
integrations.

>  not only
> RPC-friendly, but often fire-and-forget-compatible.

Sorry, this makes no sense.

> Our intuition is
> that setting up a messaging channel for those cases is overkill,

Setting up the message channel is not the issue. You have to solve the
hard part of this in any case. Defining the protocol for interaction
is the hard part. You delegate that to service providers already.

> as
> well as being harder to integrate with browser/system events and
> services.

On the contrary, having MesssageChannel postMessage solution aids integration.

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

Well you wrote the use cases so this is not convincing.

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

Yes, this is convincing, but I'm already convinced on this point. But
this point is not relevant. You've already told me you can support
creating MessageChannel and that solution delegates the protocol
definition to the end points.

jjb

Received on Friday, 17 February 2012 17:45:20 UTC