Re: Is there an existing mechanism that can be used for WebIntents?

Paul Kinlan wrote:
 > Hi Rich,
 >
 > I know we have talked a bit about this off-list in the past, and it
 > has also been discussed on other channels.

No. This is a completely different proposal to anything we have 
discussed previously. This is not about making web intents fit in to the 
existing registerProtocolHandler mechanism. This is a proposal for 
'registerProtocolHandler Level 2' in which the main point is to assign 
full HTTP charateristics to custom web protocols so that they act in the 
same ways and with all the same rights as HTTP URLs operate today.

This simple notion greatly opens up the way that we can communicate via 
custom protocols. Instead of just being restricted to opening custom 
protocols in a new tab with query string parameters we get the 
full-blown abilities that come with HTTP: the ability to POST, the 
ability to filter on Content-Types, the ability to use Custom Protocol 
URLs within a web page and within existing web tools.

 >
 > I will comment in-line as to why we think that this is not the
 > solution to the problem of connecting apps and building a successful
 > eco-system.

Comments also inline.

 >
> On Fri, Jan 20, 2012 at 5:45 AM, Rich Tibbett<richt@opera.com>  wrote:
>> Mike Hanson wrote:
>>> Here's another one - Austin King did some experiments with
>>> registerProtocolHandler (supported in Firefox and Chrome) to do a
>>> similar thing, about a year ago:
>>>
>>>
>>> http://blog.mozilla.com/webdev/2010/07/26/registerprotocolhandler-enhancing-the-federated-web/
>>
>> Could we not simply endow 'web+' protocols with full HTTP characteristics
>> (i.e. the ability to POST content towards custom protocolss) and then allow
>> developer to use these addresses through either existing web APIs like XHR
>> and Web Sockets, embed custom protocols directly within DOM elements or
>> setup Web Messaging channels by invoking a custom protocol via window.open?
>
> WI is quite an opinionated framework, it tries to say that for the
> majority of usecase a simple client-side request/response will work.

Web Intents relies on a web page being loaded in a seperate window or in 
an iframe. Once you have this it becomes a client side mechanism.

In the case that a simple channel needs setting up we just do:

[client]
var intentHandler = window.open('web+imageedit:foo.com/photo.jpg', 
'myiframe');
intentHandler.onmessage = function( msg ) {
   // Only handle a response from the user-selected service
   if( msg.source === intentHandler ) {
     dump( msg.data );
   }
}

[server]
// process image then on complete:
window.opener.postMessage({'action': 'complete' /* ... */}, '*');
// (window.opener will be set to the client page)


> Letting the developer communicate over XHR or Web Sockets or whatever
> else is a recipe for developer confusion and thus adoption.  If you
> were to build a service for image sharing, how would you tell the
> developer that you accepted XHR requests but not Web Sockets (or
> vice-versa).

It's a URL. This is currently a non-issue on the web and I expect it to 
be the same for registerProtocolHandler Level 2. How do you inform web 
pages that URLs are meant for Web Sockets or XHR communication today and 
avoid conflicts?

>
> Additionally, the web+ protocols are not as descriptive as we would
> like, yes you might be able to embed the verb into the scheme, but
> then supporting a wildcard set of data-types would be hard to define
> at a spec level, awkward to implement at a browser level and a pain to
> implement at the web dev publisher level.

If you are POSTing to a URL then you can set the Content-Type to 
whatever you wish. Either we let the service decide if it can handle the 
content when it receives it or we can let service providers submit a set 
of Content Types that they support with their registerProtocolHandler 
registration. I'm more than happy to rely on the former.

>
>> Drawing parallels with Web Intents, you would define the 'action verb'
>> within the protocol's schema, draw the content-type and other
>> characteristics from the full range of any POST headers. The data would be
>> sent in the body of a POST.
>
> This will not work with offline apps at all.  Web Intents is designed
> to be able to work completely independently from the server by
> handling the registration, invocation, selection and resolution and
> subsequently the user action in the service entirely on the client.

Web Intents opens a web page as a result of a user's intent handler 
selection. If that web paged is appcached then it will load and we will 
be able to establish a direct communication channel according to the 
snipped provided above. This works offline as much as Web Intents.

POSTing to a appcached URL will deliver that POST to the cached 
resource. It all works the same way.

>
> You also talked earlier about Web Sockets.  Is this now included or
> excluded from what you are talking about?

This is an implicit part of the mechanism, yes. Today we don't have a 
programmatic mechanism to distinguish what HTTP URLs are exposing. This 
is the same principle at work here.

>
> Remember that in Web Intents you can register all the remote services
> that you offer as a site in one page.  I don't see how this is
> resolved.

You can do the same with registerProtocolHandler.

>
>> If you wanted to set up a Web Intents messaging channel then you could do
>> window.open({customprotocol}), register a messaging listener against the
>> returned WindowProxy object and then use the WindowProxy/Window channel for
>> inter-communication ala Web Intents.
>>
>> There would be no client-side API - you would invoke custom URLs via GET or
>> POST to use them directly within existing Web APIs.
>
> Again this has no chance of working with offline apps or just purely
> on the client-side (just a side note, appcache doesn't work well with
> query parameters - so you could appcache a URL for GET requests, but
> if you want to pass it any data via the query string you need to be
> online to do it).

This is true. So I'd architect my service to not accept query parameters 
then use a pre-designed messaging channel format to pass query string 
parameters. It's a design point.

>
> On another note, there are a lot of issues with resolving where the
> messages come from using the window.onmessage API.  Imagine you have a

See example above for resolution. Also, you can add the following to the 
server-side of the transaction.

window.onmessage = function( msg ) {
   if( msg.source !== window.opener) {
     // trash messages not sent from the opener
   }
   doSomethingWithClientMessage();
}

This is really simple on either end of the transaction.

> share button, the user clicks it twice it opens two windows - because
> the RPH system will resolve the URL to open the client app has no way

Calrification, if an in-page link is clicked or window.open is used 
against a custom protocol then it opens a separate web page.

If a custom protocol is used in an XHR, WS object then it doesn't 
require the opening of another web page

> of knowing the app/url that was opened, therefore when the remote
> windows postMessage back to the client how do you resolve for which
> user action the response was for - from my experimentation you can't
> easily (you have to track window objects and keep them maintained in a

For each click I maintain the returned result of the window.open call in 
a different parameter. I can distinguish between the two really easily.

<a href="web+videoview:example.com/videos/test.webm"/>
<script>
   var clicks = [];
   var anchor = document.getElementsByTagName('a')[0];

   anchor.addEventListener( 'click', function( evt ) {
      evt.preventDefault();

      var intentHandler = window.open( anchor.href );

      clicks.push(intentHandler);
   }, false);

   window.onmessage = function( msg ) {
     for(var i in clicks) {
       if(msg.source === clicks[i]) {
         console.log( "Message is for event #" + i);

         // do something with message for click[i]

	continue;
       }
     }
   }
</script>

On the server-side each window.opener object should point to a different 
WindowProxy object of the initiating window. I'd be much more interested 
in solving this as a general problem for window.open than implementing a 
new API.

> global variable).   Imagine having to deploy this code to a blog just
> to support share buttons?  It is pretty complex and will be a huge
> maintenance nightmare.
>
> Can we just clear up one point - you mention in the earlier paragraph
> use a message listener then in the next you say use POST and GET to
> send to the server and say there is no client-side API - this reads as
> a contradiction?  How does the message and response get back to the
> invoked client app - say I want to edit an image in the browser, I
> open it up with window.open and encode the data (via JS to pass into
> window.open - maybe this would be form submit instead), I then edit
> the image in my favourite app and then what? window.postMessage back
> the data?  It can't come back in the response because we can access
> any data on the newly opened window reference - now we have client Js
> sending to the remote server data that will be sent back to the client
> via a mechanism such as postMessage.  This is hard and confusing.

This is how communication to other resources on the web works today.

A custom protocol becomes equivalent to a HTTP URL and you can do 
whatever you like with it. The UA sits in the middle to broker access to 
individual services at the user's request and proxies the request from 
the client to the server and back again. There is no concept of an XHR 
URL or a POST URL or a GET URL. It's a URL and you do want you can with it.

>
>> For POSTing to custom protocols: each schema would be free to design and
>> share their own format that, at the simplest level, would be a JSON
>> structure that those services registered for the custom protocol share.
>
> ick.  seriously?  Whilst web intents allows this, it is pretty
> constrained in saying that for the majority of cases a
> request-response semantics are the preferred solution.  That is you
> send some data of the type defined in the registration to the service
> and your receive it back all in the clientside.

Web Intents allows you to send a structured data object to the service 
side. HTTP allows you to do that too. People who use XHR do this all the 
time. So yes. Seriously.

>
> Do we really want to get into the process of defining a new spec for
> sharing a URL with associated JSON data structures?

No we don't. This would be a decentralized process much like how 
communication formats and protocols are established on the web today.

>
> WI says that if you say you will send an image you send the image
> object, it can either be a URL to the image or a representation of
> that in the client (a dataURI or Blob for instance).

You can send objects when you invoke a custom protocol via window.open 
and then the the transfer argument of the web messaging channel returned 
with that object.

>
>> No changes would be required on the server-side registration of a custom
>> protocol handler.
>
> There are no changes with WI either.  Unless you are talking about a
> server side change being updating a template to include the HTML (in
> which case we do need one change) and I think this would still happen
> with your suggestion as well.

I mean no changes at all. A service uses the registerProtocolHandler 
method in the usual way and as implemented in three browsers already.

>
> Just as an added FYI, part of the intent spec we are currently looking
> at is unifying the declaration of RPH and RCH and WI via the intent
> tag, so that you can declaratively register a content handler via an
> html element maybe of the format<intent type="image/*" />, this being
> less verbose that the associated JS, but also benefits from mime-type
> globbing etc.... We haven't specced it out yet, but it could be very
> powerful.
>
>> The major advantage of building on HTTP would be two-fold:
>>
>> 1. Extend the reach of the web democratization revolution. Developers could
>> invoke custom protocols from e.g. a native application, select a service
>> handler and get forward to their chosen web app. A full HTTP-like mechanism
>> embodies all of the principles of Web Intents but also has the ability to
>> reach far beyond the web to 'things' that can be connected to the web and
>> the web that can connect to native apps and networked connected devices and
>> services.
>
> Are you saying that WI doesn't allow this?  Both RPH and Intents are
> focused on letting the user resolve the services that they wish to use
> for the action (or in RPH's case the protocol name).  The implication
> that a full HTTP model resolved by RPH will solve everything is
> patently false.  You want to send data to a native app on the users
> machine now that App has to understand how to process HTTP Post
> requests and how to respond to them - I also worry how does the UA
> define a consistent API to call the app give it the data and then
> expect a response back - can we build this native API/bridge
> consistently so the native app developer doesn't have to build a
> Chrome Bridge, a FF bridge and Opera bridge etc?

To all intents and purposes a web application can treat a custom 
protocol url as a HTTP resource. Who _doesn't_ know how to deal with 
that today?

>
> Also, registerProtocolHandler is not HTTP like for anything other than
> encoding the data in a url, there is no real request, you don't send
> across HTTP headers to the native app, you never get a response back.

This is absolutely the purpose of the proposal here: to give custom web 
protocols all of the characteristics of HTTP URLs to enable all of the 
use cases currently being covered by Web Intents.

>
>> 2. Reverse CORS. By invoking a custom protocol, developers can communicate
>> with services residing on different origin servers. The authorization for
>> this comes from the user implicitly authorizing the cross-origin
>> communication by selecting a service provider from their UA-based custom
>> protocol handlers list.
>
> Yes, and Web Intents does this too (in the client), with a constrained
> action resolution and the added ability to also filter based on data
> type if required.

We could look in to data types. This idea isn't going away. This is, in 
effect, a candidate proposal for 'registerProtocolHandler Level 2'. We 
could discuss if and how to specify filters based on data type in that 
initiative. This would be a case of adding a single option to 
registerProtocolHandler().


Thanks for your feedback. This is a good discussion. I feel that we may 
not solve anything on this Web Intents list but I wanted to communicate 
how this problem could be solved by improving on what we already have in 
the web platform without needing to add more APIs or start any new 
initiatives.

Cheers, Rich

>
>
>> br/ Rich
>>
>>> -mike
>>>
>>>
>>> On Jan 15, 2012, at 10:23 AM, Paul Kinlan wrote:
>>>
>>>> Hi,
>>>>
>>>> This was something that I started to document under
>>>> http://webintents.org/subscribe - the intents discovery mechanism in
>>>> the spec doesn't preculde a UA from detecting this and allowing the
>>>> user to invoke an action to subscribe to the feed using their
>>>> preferred application.
>>>>
>>>> P
>>>>
>>>> On Fri, Jan 13, 2012 at 4:48 AM, Mike Kelly<mikekelly321@gmail.com
>>>> <mailto:mikekelly321@gmail.com>>  wrote:
>>>>
>>>>     Hi,
>>>>
>>>>     I was wondering whether an example of 'web intent' behaviour has
>>>>     already existed for some time:
>>>>
>>>>     The example I am thinking of is driven by atom/rss links in the head
>>>>     of HTML pages, i.e. an html page containing the following link in the
>>>>     head of the document..
>>>>
>>>>     <link rel="alternate" type="application/rss+xml" href="...." />
>>>>
>>>>     ... this causes a browser (e.g. Firefox) to present the user with the
>>>>     option to 'Subscribe to This Page' where the user can fulfil their
>>>>     'subscription intent'.
>>>>
>>>>     Would this be considered an equivalent of a web intent?
>>>>
>>>>     Cheers,
>>>>     Mike
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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<http://paul.kinlan.me/>
>>>> Skype: paul.kinlan
>>>>
>
>
>

Received on Friday, 20 January 2012 16:54:01 UTC