Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter

On 11/18/11 10:29 AM, Paul Kinlan wrote:
>
>
> On Fri, Nov 18, 2011 at 7:23 PM, Charles Pritchard <chuck@jumis.com 
> <mailto:chuck@jumis.com>> wrote:
>
>     On 11/18/11 1:40 AM, Paul Kinlan wrote:
>>
>>
>>     On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock
>>     <gbillock@google.com <mailto:gbillock@google.com>> wrote:
>>
>>         On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard
>>         <chuck@jumis.com <mailto:chuck@jumis.com>> wrote:
>>
>>             As far as I can tell, the model doesn't prohibit, nor
>>             does it encourage, the passing of MessageChannel.
>>             It's very much made for an RPC style of communication,
>>             but if the message being passed back is a channel, well
>>             that's just fine.
>>
>>             Am I mistaken? What I'm seeing is that we get
>>             MessageChannel for free, and there's no need to specify
>>             further.
>>             Individual Intent authors can do that themselves.
>>
>>
>>
>>         Yes. We envision RPC-style request/response as the sweet spot
>>         for intents. We've definitely considered use cases which are
>>         better served by opening a persistent
>>
>>     On the subject of MessageChannels, my thoughts have been that you
>>     don't pass the data across it, as you would for say "share"
>>     "image/*", but rather it is the initiation of a protocol - whose
>>     mime-type is yet to be determined; something like
>>     application/x-protocol-uucp
>
>     My concern is the plumbing of Transferable.
>     Sending Array Buffers across channels is great for short apps.
>
>     Here's the webkit meta-bug as they work on postMessage semantics.
>     https://bugs.webkit.org/show_bug.cgi?id=64629
>
>     It's a "transfer" intent. I'm transferring ownership of a buffer
>     or a stream.
>     It's still appropriate that mime types be specified. Many
>     protocols have them.
>
>     -Charles
>
>
> Sure, you can defiantly pass data across them, what I was referring to 
> (if I understand your point) is that the MessageChannel is used for 
> protocols that are more complex that the request/response that 
> webintents has now.  And to ensure that both client and service are 
> talking the same protocol then the mime type is for the protocol and 
> not the data going across it.

Yes, I understand the reference. It's important that services are 
register themselves to appropriate mime types and intents. The "intent" 
field is a simple DOMString, and it's reasonably wide-open for use. 
Should we treat the mime type field in similar manner? Web messaging is 
so-easy to use, I'd expect a flood of micro-protocols.

What's our plumbing to effectively work with the postMessage transfer 
semantic? It seems like "transfer" might be a special case intent. 
Everything else does a data copy. Transferring an array buffer means the 
current thread can no longer access that buffer.

This is, approximately, what I'm thinking about:

var intent = new Intent("http://webintents.org/transfer",
   "application/octet-stream+myprotocol",
  [messagePort, arrayBuffer]);

The "transfer" intent signals that postMessage transfer semantics are 
going to be used.

-Charles