Web Intents - the future of web apps

It seems like there should be an even simpler way to create an intent link than with a form. Something like<p><pre><code> &#60;a action="http://webintents.org/share" type="text/uri-list" data="http://kittens.com"&#62;Share Me!&#60;/a&#62; </code></pre> Presumably browsers would also be at leisure to provide access to intents in their native interface, like a share button right on the toolbar.<p>The intent choosing UI is a thorny issue. I dislike forcing the user to respond to install dialogs or limiting them to intents they have previously installed. I think my ideal browser would silently remember all the intents it has seen. When it needs me to choose one, it shows me a list of candidates I have used before (as intents), padded to some pleasant length by candidates most often visited (directly). If not all candidates fit, a "More..." option expands the list to completion.<p>Some sites will want to be certain that intents they invoke can be handled by all users. So, maybe they should be able to suggest some services to be appended to the user's (possibly empty) list.<p>Making the action field a URI could create some interesting politics. I can imagine the action space being fragmented along company lines e.g. <a href="http://facebook.com/like" rel="nofollow">http://facebook.com/like</a> vs <a href="http://google.com/plusone" rel="nofollow">http://google.com/plusone</a> vs <a href="http://twitter.com/tweet" rel="nofollow">http://twitter.com/tweet</a> etc. A flat namespace might encourage more reuse of actions and less creation of new ones. But maybe I'm just being paranoid.

This feels like an engineers vision of the web. The two benefits of this over apis are:<p>1) The user gets to choose how to perform a particular activity.<p>2) Services can be found either automatically or by the user searching for services and saving them for later.<p>Don't the majority of users want this taken care of for them? Imagine going to facebook and having to find a service to perform a friend request. That's just an irritation for a benefit that most people don't want(wow I can send an invite using SMS with this service).<p>It's also notable that there's no styling on the examples. How is the UI going to be integrated, are all of the web intents supposed to follow a standard CSS format? How about the amount of space that service takes up on the page?<p>I suspect apis are popular because they're the best fit for sharing functionality on the web. Users want curated, integrated websites, not a set of mix 'n' match components.

Interesting idea, but the examples seem very awkward. I was expecting an in-page UI instead of an HTML popup. I was expecting a cookie to save my favoured intent for later use so I didn't have to choose a service provider every time I wanted to shorten a link. I was expecting to be returned to my originating page once I was done with the intented service.

How does this relate/compare to Twitter's Web Intents? <a href="http://dev.twitter.com/pages/intents" rel="nofollow">http://dev.twitter.com/pages/intents</a>

Nice idea, but surely you can't introduce a new cross-site communications protocol without discussing the security implications?

I like this idea, my gut tells me there is something in that arena to be solved with some simple like this (maybe even a universal JSONP callback method definition for an endpoint or something for services that you can call out to for things like this?)<p>I wonder if the actual usability of this is what stymies it... for example, say SmugMug exposes their image filtering API that they use to sharpen and enhance uploaded images and Flickr exposes their geocoding API to allow you to pass in GPS coords and they write them into the JPG meta for you... what is the motivation for these services to expose these services to 3rd party (potentially competing) web applications to make use of them? I am assuming you have access to these services because you are already customers of those companies, wouldn't they want to keep you in their garden?<p>If you put this in a pot and boil the water off of it, wouldn't this idea more or less come down to the problem web services are meant to solve and in that way end up with a similar looking ecosystem?<p>Not critical of the intents idea, just trying to think of where this goes once it exists to get a better idea of how it should be designed/pitched/used/thought of.<p>Thoughts?

I have been working on something like this but a bit different for a while; you can see an example at <a href="http://cloudactions.herokuapp.com/paint/" rel="nofollow">http://cloudactions.herokuapp.com/paint/</a> or <a href="http://xdpaint.herokuapp.com" rel="nofollow">http://xdpaint.herokuapp.com</a> - I'd be curious what you think. (If you choose the Flickr open option or Imgur save option you don't need to log in with anything)<p>You can turn the iframes into popup windows if you eval 'cloud.noIframes=true' from a javascript prompt or enter 'javascript:cloud.noIframes=true' in the URL bar.<p>EDIT: There's also an older iteration of this idea at <a href="http://xdproject.org/filterizer/" rel="nofollow">http://xdproject.org/filterizer/</a>

Have you thought about defining an (optional) Integrator ID that would be dispensed by the central authority? There are a couple use cases here:<p>1- Some services that are prone to abuse may require the Integrator ID to rate limit or prevent spam. The central authority could rely on a system that makes it difficult to obtain multiple IDs.<p>2- Some services may wish to provide a revenue share to integrators as an incentive -- we can imagine that Picnik is the service, and it collects revenue from usage through ads and premium upgrades, and opts to share that revenue with integrators.

This is really a great idea.

We have built and OCR service that includes pretty cool image pre-processing feature to ensure high performance OCR. The actual OCR is done using corporate level software from ABBYY. We did this for an android app we are working on but have built the service in such a way that it could be run by another piece of software easily.<p>We will probably offer it out via a simple API but interested to know if we could also offer it via "Web Intents" - would it make sense? How could we do it?

it belongs in meta rather than as its own tag

Aren't APIs kinda sorta built for this?

This seems like one of those ideas that comes up every few years and sounds great to programmers, but never results in anything noteworthy, because it's a solution in search of a problem.

What's future is past.<p><a href="http://en.wikipedia.org/wiki/Cyberdog" rel="nofollow">http://en.wikipedia.org/wiki/Cyberdog</a> <a href="http://en.wikipedia.org/wiki/OpenDoc" rel="nofollow">http://en.wikipedia.org/wiki/OpenDoc</a> <a href="http://en.wikipedia.org/wiki/Object_Linking_and_Embedding" rel="nofollow">http://en.wikipedia.org/wiki/Object_Linking_and_Embedding</a>