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

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

From: Paul Kinlan <paulkinlan@google.com>
Date: Tue, 22 Nov 2011 15:47:03 +0000
Message-ID: <CADGdg3CJcND_yDfJkyHvEbj9sHZRbjTxBwHJ1iX=hM+_rak0CQ@mail.gmail.com>
To: Rich Tibbett <richt@opera.com>
Cc: Charles Pritchard <chuck@jumis.com>, timeless <timeless@gmail.com>, WebIntents <public-web-intents@w3.org>, Greg Billock <gbillock@google.com>
On Tue, Nov 22, 2011 at 3:32 PM, Rich Tibbett <richt@opera.com> wrote:
> 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.

The assumption is that the underlying intent system knows what share
is and that it should ignore port2.  The UserAgent at the moment
doesn't care what the action string is other than as a facility to
find other services that have said they support the same action.

I don't believe we should build that intelligence in to they system.

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

Whilst I see where you are going, one the postResult has been called
the current prototypes terminate the session and close the window.
The use cases at the moment is: a users open an app, the user switches
to that app completes their task and sends the data back to the app.
Users very rarely will keep swapping between tasks to keep applying
new filter data.

But given the example above, why not just send the data via
postMessage in the first place?  It seems simpler to keep it that way
than introducing a new optional 4th parameter.

>> 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.

It is an entangled port just as the Web Messaging API specfies[1].
The client posts on port1 and listens to responses on it, the service
recieves data on the port it has got a handle too.  startActivity uses
the structured clone algorithm, that support Transferable objects. The
third parameter, the data on the Intent constructor and must be
anything that is serializable by the Structured clone algorithm.

The service would get invoked and set up its handling abilities as such:

var port = window.intent.data;  // just assume it is port2 that got sent through
port.onmessage = ... recieve messages from the client ...
port.postMessage("blah"); // send message to the client

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html
>> 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:47:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:45 UTC