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

On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock <gbillock@google.com> wrote:

> On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard <chuck@jumis.com>wrote:
>
>> **
>> Does anybody use registerProtocolHandler in any real sense? Is
>> registerContentHandler needed? It seems like Web Intents is an evolution on
>> the concept. I don't think we're going to see convergence on those old
>> methods. I'm ready to leave them both in favor of a yet-to-be announced
>> candidate (web intents).
>>
>> URIs are better than protocols,  and Intents are better than content
>> handlers. In my opinion.
>>
>
> RPH seems to be intended primarily for mailto: (I think that's where it
> is used.) I'm not sure what the RCH usage is like. It is definitely
> possible to imagine mapping UA handling of mailto: onto web intents. The
> way I think of it is like this: RPH is basically an action with a payload.
> RCH is essentially type info with the payload. Web Intents is kind of
> off-axis with both an action and a type as well as the payload. The idea
> (taking inspiration from the pluggable usage in the Android ecosystem) is
> that the action (analogous to the "protocol") is a locus between the client
> and handling service which can be messaged to the user in a well-understood
> way. (i.e. instead of just saying "here's some data, do whatever you want
> with it," which is a more content-type-driven
>
>
> 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 channel. It isn't clear to me as yet what to do about those.
> They definitely imply a more well-specified protocol to be pursued over
> that channel. Web Intents as an API doesn't really include or exclude that
> in the current form.
>
> On the other hand, it'd be a really nice application of the Web Intents
> permissions mechanism to be able to connect up, say, an SSH connection
> using Web Intents, so that I could write an in-browser terminal which could
> then be attached to a secure socket by the user.
>
> At this point, I'm not sure whether this kind of persistent connection use
> case is far enough from Web Intents to want to exclude it, or close enough
> to want to include it explicitly. Our early belief is that we aren't ruling
> it out with the proposed API, since MessageChannels could be provided or
> returned in the payload data. On the other hand, we haven't chosen to
> explicitly include such usage.
>
> But a lot of this stuff just comes with nice platform integration; I just
> tried passing Blob objects through intents in Chrome Tip-of-Tree with our
> prototype, and it Just Works, allowing a really appealing vision into what
> "upload" intents and file interactions could be like. Wins like that make
> me think that focusing on the sweet spot RPC interaction will not paint us
> into a corner.
>

This is awesome, anything that is Serialzable is via the structured clone
will work, so now we can pass File Objects between services, ImageData....
And MessageChannels.

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

On the earlier subject of demos, the current demos are at
http://demos.webintents.org/ please note, twitpic does not work and I will
be removing it from the list today until I have it working and I will be
adding more over the coming days.

re:Dave Ragget - the case is in one of the demos, "save image", which hooks
up with "imgur" API.  There we pass the data from the client app
(ImageStudio) to Imgur and the imgur service will handle the notifications
to the user about the upload progress (via an XMLHttpRequest), at this
point ImageStudio doesn't need to know or care about the progress of the
upload, other than it completes or fails.

P



>
> -Greg
>
>
>


-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan