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

I've singled out MessagePort in the idea we'd just re-use existing 
infrastructure from there, for sophisticated cases.
Unless there are alternative proposals, I'd like to see MessagePort 
referenced in the Intents spec.

With message passing, we have an event.origin attribute that we can use 
that to locally store whatever states we need to.
So if there are persisted states, I can do something easy like 
localStorage[event.origin].

channel.port1.onmessage = function (event) {
   if(event.data == "START") 
channel.port1.postMessage(localStorage[event.origin]);
   if(event.data.substr(0,5) == "SAVE ") localStorage[event.origin] = 
event.data.substr(5);
};

That's if I'm going with the more complicated web messaging with web 
intents model.
For simple RPC-style pickers, like the Image picker, this kind of work 
isn't necessary.

Persistable seems a little like "always open with this application/open 
with this application by default". Isn't that something that the UA can 
handle independently?
It might need a little help and/or hinting, but startActivity doesn't 
necessarily require prompting the user for action.


-Charles

On 11/18/2011 2:55 PM, Greg Billock wrote:
> Ideally, any Transferable object should be able to move through the 
> serialization layer and be part of an intent payload or return type, 
> including MessagePort. This allows sophisticated use cases like 
> establishing persistent connections, transferring file objects via 
> blobs, and so forth.
>
> As currently envisioned, those use cases will require an additional 
> layer of specification. (The "myprotocol" above encapsulates a lot of 
> that hard work!)
>
> Something even further in this direction is a "Persistable" 
> connection; that is, a url-type reference clients could store locally 
> and then use to connect up again in subsequent sessions. This would 
> allow for persistent permission grants and service connections.
>
> Our sense while developing the proposal was that the common case will 
> be RPC-style copy-by-value type semantics where you'll just wrap up 
> the picture, link, vcard, etc. and send it to the service for 
> processing and possible response. But I definitely think we want to 
> take care not to rule out these more sophisticated use cases, because 
> the intents modality of getting the user and UA in the loop while 
> hooking these things up is a very powerful capabilities-style 
> architecture for great app integration while being able to maintain 
> the proper level of good sandboxing.
>
>
> On Fri, Nov 18, 2011 at 2:42 PM, Charles Pritchard <chuck@jumis.com 
> <mailto: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
>
>
>     -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 <mailto: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]);
>>
>
>
>