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

We haven't been able to think of a scenario where we want to send data
and also a port.  To me it just doesn't make sense.  But we should
explore the use case with a hypothetical implementation of client and
service using both models.  The example of share is really bad. I
really really really don't want to get in to passing a channel with a
url for "share" and "text/uri-list".  How is client or service
supposed to know that either side can handle a channel AND what should
be shared on it?  They can't and there is no need.

The combination of action, type (which is the protocol) and port as
the data object are more than enough.

Someone mentioned earlier get-temperature as an example:
var channel = new MessageChannel()
var i = new Intent('get-temperature',
"application/octet-stream+myprotocol", channel.port2)
navigator.startActivity(i);

channel.port1.onmessage = .... do some magic with temperature sensor data ....

The client and service both agree they will be talking over a channel
given that data type is a MIME type declaration.

P

On Tue, Nov 22, 2011 at 2:47 PM, Rich Tibbett <richt@opera.com> wrote:
> On Fri, Nov 18, 2011 at 2:42 PM, Charles Pritchard <chuck@jumis.com> wrote:
>> **
>> Thanks for exploring this complex use case. This is an edge case, and > I
>> appreciate you taking the time.
>>
>> Here's my understanding:
>>
>> The following sends an entangled port through intents. The client can >
>> then dispatch a Transferable ArrayBuffer.
>>
>> var channel = new MessageChannel();
>>
>> var intent = new Intent("http://webintents.org/transfer",
>>   "application/octet-stream+myprotocol", channel.port2);
>> channel.port1.onmessage = function (event) {
>>   if(event.data == "OK")
>>   channel.port1.postMessage("DATA", [myArrayBuffer], event.origin);
>> };
>> window.navigator.startActivity(intent);
>>
>> This extra work is to ensure the ArrayBuffer is neutered:
>> http://www.khronos.org/registry/typedarray/specs/latest/#9.2
>
> So my understanding is that we'd be better of with an optional
> sequence<Transferable> parameter in the Intent constructor rather than
> making this behavior specific to a 'transfer' action as suggested above.
>
> I don't see why the target Intent should need to be
> 'http://webintents.org/transfer'. Presumably, you might want to transfer
> objects in combination with any other intent.
>
> For example, a valid example for setting up the MessageChannel (by
> transferring channel.port2 to the Intent Handler) above could just be:
>
> var intent = new Intent("http://webintents.org/share",
>   "text/uri-list", "http://foo.com/bar", [channel.port2]);
>
> How exactly the transferable objects can be captured by the intent handler
> page should be discussed. I'd imagine the port2 in the transferable sequence
> I passed above would be available at something like
> window.intent.transferData[0].
>
> - Rich
>
>>
>>
>> -Charles
>>
>>
>> On 11/18/11 1:52 PM, Paul Kinlan wrote:
>>
>> The Pseudo code you have is nearly exactly how we envisaged it.  We just
>> passed the port, then the data over the port as that could be part of the
>> lower level protocol (the 'myprotocol' bit).
>>
>>
>>  P
>>
>> On Fri, Nov 18, 2011 at 10:40 PM, Charles Pritchard
>> <chuck@jumis.com>wrote:
>>
>>> 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]);
>>>
>>
>>
>>
>



-- 
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 Tuesday, 22 November 2011 15:04:29 UTC