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

Great discussion!

A couple more things to consider:

1. Web Intents locators aren't uniform. They by definition point to a
user-configurable endpoint. Perhaps a better interpretation of RPH is
that "mailto:" "urls" aren't really urls, they are more akin to
content types, for which the user has registered a particular sort of
handler.

What this means for interpreting web intents specifiers as urls is
that, while it is of course possible to coerce any flat data into a
url, the parts don't really mean what the parts of a url mean. There's
no origin concept (or if there is, it must be imported separately).
There's no natural scheme -- it isn't the usual case that an "http" or
similar protocol is used for delivery, and in fact, for some use cases
where the UA is interacting with other local machinery, it may not be
dispatched through any web protocol at all.

Those considerations suggest to me that modeling a web intents
specifier as a url is awkward, so I sympathize with the kinds of
awkwardnesses Paul is bringing up. At the same time, mapping these
specifiers onto urls is intriguing -- being able to use them as such
directly in forms and <a> tags seems like an interesting option, and
we've talked about that before in other discussions.

2. A big issue is that when web pages are providing intent services,
we're essentially treating web pages as the "server" for the client
page. This happens now with iframes, postMessage, and the like, so
we've wanted to ensure the spec supports (or does not forbid) a way to
do similar MessagePort transmission. But the huge variety of ways this
kind of communication is done is an indication to me that the spec
will be most useful if it specifies the interaction format more fully.
Once you take that approach, it seems to me that the idea that most
interactions are RPC-style (just like most HTTP requests are
RPC-style) is an inevitable outcome.

The thing the current spec does where I think intuitions differ the
most is that we've made this RPC-style interaction the main focus,
with the possibility of using it to do longer-term session
establishment via MessagePort exchange, instead of making session
establishment the baseline and building an RPC-style protocol atop
that. There are a few reasons we've taken that approach.

First of all, as Paul says, we think it is simpler. Instead of needing
lots of Javascript tooling reducing the entropy about exactly how the
communication protocol works (do I send you a MessagePort, or do you
send me one? How do I know it's established? Do I send a SYN message
through, and then you reply back, then I send the data payload? Or do
you send me a MessagePort, but it is speced so that it must have a
listener already set up on it?) There are all kinds of fiddly points
here, which must be gotten right. So obviously they can, and
developers would use library superstructure to do so. Part of the
attraction of the RPC-first, though, is that it simplifies this
dramatically. It's a lot closer to "API is protocol," where you can't
startActivity without an Intent, which you have to create with your
data (it's immutable). On the receiver side, window.intent is
populated as your JS starts to execute, so you don't have to jump
through protocol hoops to figure out when you may or may not have to
register a listener on something. The object is just sitting there.
You can invoke its API when you want.

Second, the desire to interact with other services is an explicit
goal, and an RPC-style interface is more flexible for use cases there.
If I want to load an external handler program, mapping an RPC-style
call to it is a lot easier than demanding that the handler program
support a particular kind of protocol interaction with the UA. Mapping
intent interactions to various processes within the UA is also easier:
modules don't need to be built with the protocol in them, they just
need to be able to ingest the data packet and call back into the
Javascript. Browser modules are good at that, and it would be harder
to make them good at negotiating a more complex protocol whose end
result is basically to do that RPC-style task.

Third, an RPC-style interaction allows the UA more inspection
opportunities on the wire for filtering, checking, or otherwise
routing the communications. Suppose I want to share something to two
places. It is much easier to build an RPC-style service switch which
means the UA can provide the user with the means to do things like
that, than to build a protocol interceptor if both sides need to be
talking back and forth to each other.

None of these things are impossible with a messaging-first approach to
the feature, but they impose a lot more overhead. That's what's
driving our design choice to go with an RPC-first approach. That is,
while it is true that a messaging-first approach requires less
specification change, it also leaves the use cases mostly unhandled.

So in the original context, while url-style specifiers aren't
necessarily forced to coincide with a messaging-first approach, they
are definitely more natural to use there, and less natural to use for
an RPC-first approach.

3. This is less of an issue, but I wanted to mention it. One main goal
we have for intents is that their semantics carry a strong
user-initiated signal to services. Encoding them as urls for use with
window.open and such is certainly not incompatible with this (witness
popup blockers), but a url by itself doesn't really model this
currently. Perhaps this should be re-examined (i.e. pages wishing to
establish data-level non-user-initiated contacts with intents
services), but the way we currently think about the feature, the
permissioning context is one of explicit user interaction. We think
there are ways to use intents to establish cross-session connections
(i.e. storing the results of an intent invocation in local storage)
which address some of those use cases.

Again, this is a great discussion. It really gets to the heart of what
the feature is doing and why.

(I'm not sure who all is on public-web-intents now, so I've included
you directly.)


On Fri, Jan 20, 2012 at 8:53 AM, Rich Tibbett <richt@opera.com> wrote:
> 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 18:28:23 UTC