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

I'd like to request that people stop sending posts about web intents to

public-webapps@w3.org and public-device-apis@w3.org

The new list exists and should be used:
http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/

On 11/18/11, Charles Pritchard <chuck@jumis.com> wrote:
> 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
>
>

-- 
Sent from my mobile device

Received on Friday, 18 November 2011 21:36:42 UTC