Re: A simpler, webbier approach to Web Intents?

At this level of detail, we should be examining the draft directly,
not making analogies. If there are particular things you think a
postMessage solution to the problem would be good at, it'd be most
helpful to make a concrete proposal.

On Fri, Feb 17, 2012 at 9:44 AM, John J Barton
<johnjbarton@johnjbarton.com> wrote:
> 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 19:57:45 UTC