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

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?

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.

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.

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.

No changes would be required on the server-side registration of a custom 
protocol handler.

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.

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.

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 13:46:15 UTC