For those unfamiliar with Android, it has a system where you send off a named Intent (I don't know the real names off hand so lets say Intent.PHONE_CALL) and another app handles it.
You might have several apps that can handle such an intent, or you have a default one - and the intent triggers that app to open and depending on various things an action to take place.
As Ballista states, they're looking at editing documents etc.
The one place where this might be creating functionality that already exists is URIs. For example, mailto:firstname.lastname@example.org. Although URI's are supposed to simply indicate a resource and not really act as a full blown intent system.
Either way, things such as this bring the web closer and closer to being able to do the sort of things we "just expect" from native apps. It should be worthwhile to watch.
It worked well enough abroad that I signed up for T-Mobile's $30/5GB plan when I came back to the US. All my phone calls are routed over my data plan, and none of the apps on my phone need to know that to keep working correctly. I can open Yelp and tap Call in a restaurant listing to make a VoIP call in Hangouts just as easily as someone on a traditional plan can with the Phone app.
> ...We determine the people you might enjoy following based on your visits to websites in the Twitter ecosystem (sites that have integrated Twitter buttons or widgets)... (https://support.twitter.com/articles/20169421)
I think I am more confused than anything. On the product itself, they don't seem to be aware of pajax.
I think this is what the authors are (somewhat clumsily) alluding to.
Here's some more information (it's not an ideal source, but I wasn't able to find a better one; maybe someone else will): http://www.nytimes.com/2014/04/14/opinion/my-ideas-my-bosss-...
But for this to be a full success, the other vendors will also need to come on board. Can't think of a more important feature that needs standardization than intents. So once this gets standardized:
- Mozilla probably will implement, because (barring minor transgressions) they care about users more than everyone else.
- Microsoft may, because any chance of increasing their 2.5% market share depends on maximal interop and web-apps being a genuine cross-platform solution to make up for the lack of apps in their App store.
- Apple and Safari. This is going to take time, if ever. They might even come up with their own solution, requiring developers to implement two solutions to do the same thing. Strategy-wise, web apps becoming more potent is not in their interest.
We aren't going to standardize first, then expect buy-in from other browser vendors. We expect to have a discussion (with the web community, including web developers and browser vendors), and from there either jointly standardize/implement, or not. We won't commit to this in Chrome unless we get cooperation from the web community.
In all seriousness, even if others tried before, they may only have failed because of having no visibility or bad marketing. This has the support of Chromium behind it, so it might be the only key point that would make this viable and adopted widely.
See https://developers.google.com/open-source/projects for more, and if you'd like to come work for a company that lets you use 20% time to create new projects or contribute to existing projects, visit http://www.google.com/about/careers/.
I understand the point you are trying to make but at some point it becomes semantics.
ie they want to give their engineers the ability to do neat projects—projects that could potentially make money—but they don't want to back each one fully, and they don't want to have their brand tarnished if the project fails.
It could fail. And even if it succeeds, it isn't ever going to be a "product", but a Web Platform feature.
*Note: I am the person leading this project.