W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2011

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

From: timeless <timeless@gmail.com>
Date: Fri, 18 Nov 2011 13:36:11 -0800
Message-ID: <CAACrNNdTkNdqUcqiinZgk94sSvLvTx3zcXy-PQQx__B8qn9csA@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>, Paul Kinlan <paulkinlan@google.com>, Greg Billock <gbillock@google.com>, public-webapps Group WG <public-webapps@w3.org>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
I'd like to request that people stop sending posts about web intents to

public-webapps@w3.org and public-device-apis@w3.org

The new list exists and should be used:

On 11/18/11, Charles Pritchard <chuck@jumis.com> wrote:
> On 11/18/11 10:29 AM, Paul Kinlan wrote:
>> On Fri, Nov 18, 2011 at 7:23 PM, Charles Pritchard <chuck@jumis.com
>> <mailto:chuck@jumis.com>> wrote:
>>     On 11/18/11 1:40 AM, Paul Kinlan wrote:
>>>     On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock
>>>     <gbillock@google.com <mailto:gbillock@google.com>> wrote:
>>>         On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard
>>>         <chuck@jumis.com <mailto:chuck@jumis.com>> wrote:
>>>             As far as I can tell, the model doesn't prohibit, nor
>>>             does it encourage, the passing of MessageChannel.
>>>             It's very much made for an RPC style of communication,
>>>             but if the message being passed back is a channel, well
>>>             that's just fine.
>>>             Am I mistaken? What I'm seeing is that we get
>>>             MessageChannel for free, and there's no need to specify
>>>             further.
>>>             Individual Intent authors can do that themselves.
>>>         Yes. We envision RPC-style request/response as the sweet spot
>>>         for intents. We've definitely considered use cases which are
>>>         better served by opening a persistent
>>>     On the subject of MessageChannels, my thoughts have been that you
>>>     don't pass the data across it, as you would for say "share"
>>>     "image/*", but rather it is the initiation of a protocol - whose
>>>     mime-type is yet to be determined; something like
>>>     application/x-protocol-uucp
>>     My concern is the plumbing of Transferable.
>>     Sending Array Buffers across channels is great for short apps.
>>     Here's the webkit meta-bug as they work on postMessage semantics.
>>     https://bugs.webkit.org/show_bug.cgi?id=64629
>>     It's a "transfer" intent. I'm transferring ownership of a buffer
>>     or a stream.
>>     It's still appropriate that mime types be specified. Many
>>     protocols have them.
>>     -Charles
>> Sure, you can defiantly pass data across them, what I was referring to
>> (if I understand your point) is that the MessageChannel is used for
>> protocols that are more complex that the request/response that
>> webintents has now.  And to ensure that both client and service are
>> talking the same protocol then the mime type is for the protocol and
>> not the data going across it.
> Yes, I understand the reference. It's important that services are
> register themselves to appropriate mime types and intents. The "intent"
> field is a simple DOMString, and it's reasonably wide-open for use.
> Should we treat the mime type field in similar manner? Web messaging is
> so-easy to use, I'd expect a flood of micro-protocols.
> What's our plumbing to effectively work with the postMessage transfer
> semantic? It seems like "transfer" might be a special case intent.
> Everything else does a data copy. Transferring an array buffer means the
> current thread can no longer access that buffer.
> This is, approximately, what I'm thinking about:
> var intent = new Intent("http://webintents.org/transfer",
>    "application/octet-stream+myprotocol",
>   [messagePort, arrayBuffer]);
> The "transfer" intent signals that postMessage transfer semantics are
> going to be used.
> -Charles

Sent from my mobile device
Received on Friday, 18 November 2011 21:36:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:51 UTC