On 11/18/11 10:29 AM, Paul Kinlan wrote:
On Fri, Nov 18, 2011 at 7:23 PM, Charles Pritchard <ch...@jumis.com
<mailto:ch...@jumis.com>> wrote:
On 11/18/11 1:40 AM, Paul Kinlan wrote:
On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock
<gbill...@google.com <mailto:gbill...@google.com>> wrote:
On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard
<ch...@jumis.com <mailto:ch...@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
