W3C home > Mailing lists > Public > public-web-intents@w3.org > November 2011

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

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 18 Nov 2011 13:40:36 -0800
Message-ID: <4EC6D0D4.6010908@jumis.com>
To: timeless <timeless@gmail.com>
CC: Paul Kinlan <paulkinlan@google.com>, Greg Billock <gbillock@google.com>, WebIntents <public-web-intents@w3.org>
Carrying this thread over to the web intents mailing list.

The current issue I'm asking about, in this thread, is how we might 
present the postMessage transfer semantic in Web Intents.

Web Intents currently works much like postMessage(message). The 
Transferable semantic is relatively new to Web Messaging
and allows the transfer of Array Buffer objects and MessagePorts.

In pseudo-code:

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



On 11/18/11 1:36 PM, timeless wrote:
> 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
>>
>>
Received on Friday, 18 November 2011 21:41:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 18 November 2011 21:41:02 GMT