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

On 11/13/11 3:18 PM, Paul Kinlan wrote:
>
> On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard <chuck@jumis.com 
> <mailto:chuck@jumis.com>> wrote:
>
>     On 11/10/11 3:10 PM, Greg Billock wrote:
>>
>>
>>     On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett <richt@opera.com
>>     <mailto:richt@opera.com>> wrote:
>>
>>         Dominique Hazael-Massieux wrote:
>>
>>             Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a
>>             écrit :
>>
>>                 Hi
>>                 a.) to register a URL endpoint as an intent provider
>>                 the user must visit
>>                 a web page (presumably hosted by the target device
>>                 itself) and capture
>>                 the intent registration from that page before that
>>                 intent provider can
>>                 be used within the UA.
>>
>>
>>             My understanding is that this is not a MUST at all, but
>>             the way
>>             Web-based services can be added by a user.
>>
>>
>>     Yes. The API as currently proposed has a way for web apps to
>>     register services, but it is not intended to limit the ability of
>>     the user agent to register services by other methods. If you look
>>     at our Chromium commits, we're experimenting with ways to
>>     register services through installation of web apps, for instance.
>>     Registering handlers through local network discovery or
>>     interaction with the host OS also seems like a promising direction.
>
>     Has there been further movement toward the existing
>     register*Handler APIs:
>     http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers
>
>     I've practiced with those methods and from a usability
>     perspective, I'm starting to think those html5 methods are not
>     going to be worth using.
>     Whatever the end-case, Web Intents seems to be where the UI is
>     going to evolve.
>
>     I understand that from the Chromium-OS side, Web Intents is likely
>     to take over the fileHandlers permission.
>     That tells me that registerContentHandler is not going to happen.
>
>
> The intent model can support "view" with the associated MIME-type 
> which is what regsiterContentHandler does.  The point we need to 
> discuss is registerContentHandler will implicitly start when a file is 
> loaded with that mime-type, so should a UA initiate "startActivity" 
> implicitly with a "view", the detected mime type and the file data?
>

Seems like the UA gets to make all of the decisions here.

I think the disposition=inline vs. [a download] really sets up the 
intent well. If the anchor is marked for inline, it makes a lot of sense 
that the UA would check on its registered intents for handling it 
implicitly. There's no reason to push authors into triggering intents 
when the user can setup those preferences on their own.

PDF is a good model for this one... it's a "view" situation and it's 
likely to have only one viewer, and it's also likely to be viewed 
inline. Mozilla's work on PDF.js is certainly showing the power of web 
app registration for this complex file format. I know if I register 
pdf.js as my PDF viewer, that's what I want to pop up. I also know that, 
if I'm running Chrome, I want, somewhere, the option of switching 
between the Foxit and Mozilla viewers.

I'm not really happy with the Chrome interface for adding and removing 
registered protocol handlers. It's so buried, nobody is going to know 
about it. Web Intents really fills that gap of "Open With..." and 
context menus. I find the existing context-menu solution distasteful: a 
background page just so I can register a link? ugh!#$.

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.


>>
>>         Thanks for the quick reply and good to ensure this stuff gets
>>         captured in the TF charter.
>>
>>         As Chaals said, let's get going on this. The concept of Web
>>         Intents is great and we're not married to any particular
>>         proposal at this point. We can see if it works for our UCs
>>         when the task force kicks off.
>>
>>
>>
>>     Clarke Stevens asked about a discovery mechanism whereby a client
>>     page discovers a set of local network devices which is then
>>     updated by an event driven mechanism. As currently sketched out,
>>     there's room in our web intents proposal for the return of a
>>     MessagePort for persistent communication. The proposal doesn't
>>     focus on that problem, though. It is aimed more at an RPC-style
>>     request/response interaction paradigm. Web Intents, the way we're
>>     currently thinking about it, has a lot to do with user consent to
>>     the connection between the applications. When there's a
>>     persistent connection, that consent model starts to break down.
>>     That said, there are definitely use cases for which establishing
>>     a persistent connection is appropriate. I'm eager to discuss how
>>     to best handle those cases as the TF starts up. I think that'll
>>     be a key focus of refinement.
>
>     Hixie made a good point when he asked us to review Web Messaging.
>     Intents as it's implemented by Google -- and it's already
>     happening -- Google started this push awhile ago and I get the
>     impression that Paul Kinlan has high level support -- intents as
>     it's implemented is built upon Web Messaging and postMessage dynamics.
>
>     postMessage has MessagePort and Transferable arrays (thank
>     goodness). I believe those semantics already solve issues of RPC,
>     bi-di and zero-copy. They've had years of work put into them to
>     get to this place of consensus.
>
>     timeless brought up some excellent corner cases that I hope are
>     discussed soon in the upcoming TF mailing list. That stated, I
>     think building Intents atop postMessage is the right move. Web
>     Messaging has already solved many of the difficult problems.
>
>
> They have also introduced a lot of problems.  The RPC style isn't 
> easily supported over MessageChannel and from the developer side of 
> the things the less they have to do the less chance there is for error 
> (i.e, removing the need to close channels, removing the need to know 
> if the response should be 1 or n responses) and the 
> higher likelihood of adoption. All being said, there will be a class 
> of applications where that channel based communication with it's own 
> protocols will be needed and we should discuss that (it was something 
> we have talked about by passing a message port as the data with the 
> intent), but the model we have now feels very good when developing 
> against it.

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.


>     As far as I can tell, Web Intents adds another high level
>     semantic: the "Intent" semantic. I've proposed previously that
>     intents could work over HTTP in addition to the browser and OS
>     interoperability, simply by adding a "Web-Intent(s):" header onto
>     Web Sockets and HTTP RPC requests.
>
>
> It is interesting, some of the applications I have built have had to 
> read the state in JS and then send the data to the server via XHR, 
> removing this step would ease the pain for developers and can make it 
> a more seamless experience for the user. It is something we should 
> discuss further IMO.

Even the MessageChannel concept can work over Web Sockets. So can 
postMessage ( ArrayBuffer ) -- once the server has received the 
ArrayBuffer, the client can clear it from RAM.

As developers, we can often make things seamless for the user. The thing 
is, I think it can be fairly seamless for the developer as well.


>     A Web-Intent may have a mime-type, it'll have some kind of message
>     body, perhaps some arguments -- the one thing it adds onto
>     existing semantics is yet-another text field describing the
>     intent. That extra dimension of information seems sufficient to
>     handle many use cases -- yet to be discussed on the Web Intents TF
>     list.
>
>
> Can't wait.

Well, if it's this easy, then I guess I'll find something more difficult 
to discuss ;-)
Onward to "discovery" intents.


-Charles