Re: Exploring an Intents protocol for web messaging

On Sat, Feb 11, 2012 at 2:33 PM, Paul Kinlan <paulkinlan@google.com> wrote:
...
> Not wanting to hijack the thread, but I was toying with the idea of
> `[iframe|windowProxy].startActivity()` the other day. It would still have
> all the same semantics and benefits of webintents now.  If I the developer
> know the service I want to use, why should I go through intents picker to
> take advantage of the API?

I don't know what startActivity() means, but I interpret your question this way:

A cross-domain registration and discovery solution is built on a
cross-domain connection solution. Shouldn't the cross-domain
connection solution be usable in cases where discovery is not needed?

Or I could say it in a way that I think Charles was hinting at:

Wouldn't it be cool if the same cross-domain connection solution for
inter-web-page communications also worked for inter-frame
communications?


> With this we still get the request/response
> semantics and the ability to use MessageChannel (which is a lot lot nicer
> than plain post-message) and remove the dance/ping.  I suspect at first
> people will huff and puff at the idea, but I like it and I wanted to throw
> it out there.

I think the dance/ping is fundamental to communications, so I guess
you mean "move the dance/ping into the browser code".

>
> A solution would be very useful for inline-widgets that support a consistent
> interface AND the developer knows the service it wants to embed (and
> probably trusts as well).

I guess you mean "in-page widgets", that is independent, encapsulated
modules with a narrow interface and sub-task user-interface
implemented in an iframe and hosted within a web page right?

The narrow interface, encapsulated global scope, and
container-controlled graphical area allow lots of freedom to change
implementations of the page and the widget. This in turn allows
specialization by the widget devs and re-use of the widget across
apps.

>
> In the case of "share", the developer might embed the the twitter widget and
> later switch it out for fb, but because they support the same action the
> world is happier.

Yes, I think I the said the same thing in a much geekier way ;-)

>
> The issues/questions/thoughts that I have are:
>
> For most solutions there is a larger dance that is needed and I hate dances

Ever try Zydeco?

>
> iframe/parent will have to agree they are sending the correct data

I'm not sure what you mean here. This seems obvious and without
alternative. The agreement mechanism can be rigid like type-checking
or flexible like http. But there has to be agreement.

> the developer has to do a lot of work - post message is still not as widely
> used in the wild (it is only really used by widget vendors such FB and Plus
> etc because they know they are communication back to their own service and
> they know the entire service side API).
> We need to know when we can send the data

I believe this matches the gist of my post on webapps: we need a
standard connection ceremony (dance) for cross-domain communications.

> What happens if we send more than one message down the channel

During the connection ceremony both ends must tolerate multiple
messages. The ceremony is fundamentally asynchronous. It's exactly
like setting up a date via email: if you really want to go out you
have to  tolerate both delays and the exuberance of "did you get my
email?".

After connection mostly developers want request/response logic: no
repeats allowed.

The connection ceremony is fundamentally unlike the main
communications. That's why it's really annoying to use one channel for
both. So using addEventListener('message', handler, false) for set up
and MessageChannel for the rest is a clear winner.

>
> There is no need for client to send service a ping, instead service should
> send client a ping when it is ready with its capabilities.

Of course I can claim that this is backwards: clients say "jump" and
services should respond with "how high?".  As a client I don't want
services bombarding me with "do you want to dance?"  But then I don't
know what you mean by client and service here.

>
> But the assumption is that none of this is needed if the developer knows the
> iframe they are embedding.

If the developer knows what iframe they are embedding, they don't need
'discovery', the key part of WebIntents. But they do need the same
kind of connection-establishing ceremony (dance). Moreover since the
intermediate wire protocol is JSON in both cases and the dominant
language is JavaScript, there is a lot of potential for common code to
handle messages coming over the channel.

Further more there is a nice opportunity in between the pure
WebIntents use case and the pure developer-knows use case. In the
middle ground we have frameworks that allow end-user customization by
plugin selection. A concrete example in the Web space is the Orion Web
IDE which has a cross-domain iframe-based registry and postMessage
based communications system.

Trying to read between the lines here Paul, I guess your point of view
is that the browser should have an API that hands the page a port to
the iframe and vice versa, the iframe should get a port to the page?

jjb

>
> I am warming to the idea of startActivity on [iframe/windowProxy]
>
> [1] http://paul.kinlan.me/webmessaging-is-broken
>
>
> On Sat, Feb 11, 2012 at 8:52 PM, Charles Pritchard <chuck@jumis.com> wrote:
>>
>> In a thread on Web Apps, titled, "connection ceremony for iframe
>> postMessage communications", John Barton brought up some ideas about
>> formalizing an iframe web messaging protocol.
>>
>> The web intents prototype/shim, over at http://webintents.org/ does
>> something very similar.
>>
>> I'd like to explore a protocol for handling web intents over postMessage
>> semantics. It may be very similar, or even match the semantics of the shim,
>> or it may be a little different.
>>
>> John and I seem to have come to the same conclusion that a "ping" message
>> is needed, to setup the handshake. In the case of postMessage, registration
>> may not be an issue/on the table.
>> It's more likely the case that site A wants to interface to site B, and
>> site B has a general mechanism for any site to do so.
>>
>>
>> -Charles
>>
>
>
>
> --
> Paul Kinlan
> Developer Advocate @ Google for Chrome and HTML5
> G+: http://plus.ly/paul.kinlan
> t: +447730517944
> tw: @Paul_Kinlan
> LinkedIn: http://uk.linkedin.com/in/paulkinlan
> Blog: http://paul.kinlan.me
> Skype: paul.kinlan
>

Received on Sunday, 12 February 2012 18:08:56 UTC