- From: Rich Tibbett <richt@opera.com>
- Date: Tue, 22 Nov 2011 16:32:44 +0100
- To: Paul Kinlan <paulkinlan@google.com>
- CC: Charles Pritchard <chuck@jumis.com>, timeless <timeless@gmail.com>, WebIntents <public-web-intents@w3.org>, Greg Billock <gbillock@google.com>
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