registerProtocolHandler is designed to handle cases where there is a specific type of application that needs to be launched, commonly via an anchor or form, for instance "mailto://". When a user launches a link with mailto defined it will open the registered native application or web application.
We don't think this goes quite far enough, the protocol handlers have no concept of what data will be presented to the launched application; what happens when the opened application can't handle the data? how do you send an image to an app? There is no way to communicate data back to the calling application. Web Intents solves both of these problems.
Web Intents uses a filter mechanism to let applications register the commands that they wish to handle and also the data-types that they can support.
The answer is very similar to the problems that navigator.registerProtocolHandler suffers from. It's primary usecase is for registering the browser as a handler for a type of file data, it doesn't provide context as to the action's it can perform on those files.
We want to provide a picker and application context to the user that is not spoofable by a malicious page. An in-page in-line solution would look and feel very similar to an iframe and thus could be spoofable. It would be nearly impossible to provide an interface that could not be spoofed by a site.
The user experience of having services that are invisible adds greater complexity to the user-agent and the user experience.
Very well. Web Intents is designed to be an entirely clientside discovery and communication channel.
The native implementation requires no 3rd party scripts or hosting. It is built in as a function of the User Agent.
The action in the intent tag is a URL to facilitate the following cases:
Throughout the Android intent eco-system you see regular use of com.domain.intentname for custom intents. Looking at Android (not the external apps), every intent is already in a namespace, the documentation suggests that everyone prefix it with their package name, therefore "android.intent.action.SEND" is different "com.example.intent.SEND". Given that they are namespaced to a physical location on an Android device (the package) translating this to the web, is through URL's.
Type strings are a filter used by the User agent to resolve the list of services that are known to be able to handle a particular type of data. For example, there is no point in listing a service that can only edit images at the start of an activity to edit audio.
Type strings are based on a MIME-type style syntax and can be resolved either via a full string match or via a simple wildcard system.
Wildcard types can be specified both in the intent tag and at the time of "startActivity".