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

Paul Kinlan wrote:
> 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.

My assumption is that there would be a common description of what any 
particular Intent action does. You're right there is no expectation in 
the provided example that http://webintents.org/share is defined to 
allow any messaging channel communication. Any 
http://webintents.org/share handler would simply ignore that port2 
parameter.

However, another intent could allow subsequent messaging via a channel 
after an initial exchange of data. We should explore real use cases for 
that. For example, a user invokes a 'http://foo.com/editimage' intent 
action with some initial image data and then their web app can apply 
real-time filters to the image via the provided messaging channel - as 
long as http://foo.com/editimage is defined to work with a messaging 
channel in the first place).

>
> 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);
>

I'm missing how channel.port2 gets propagated to the selected Intent 
Handler if it is not designated as a Transferable parameter. If the 
_exact_ port2 object is not transferred, then there is no messaging 
channel to use in the first place...

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

...and this will never get called since the Intent Handler has no way to 
postMessage on the channel.port2 parameter.

I may be missing a trick here.

>
> 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]);
>>>>
>>>
>>>
>
>
>

Received on Tuesday, 22 November 2011 15:34:02 UTC