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

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.

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.

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.
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).

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.

>
> 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.

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

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.

>
> 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).

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
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
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
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.

>
> 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.

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

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).

>
> 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.

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?

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.

>
> 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.


>
> 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
>>>
>>
>



-- 
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

Received on Friday, 20 January 2012 15:47:19 UTC