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

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