Web Activities: counter-proposal to Web Intents

Hi,

With some people at Mozilla, we've been working on an API similar to Web
Intents in some points but distant enough to be a counter-proposal. We
believe that the API is now in a good enough shape to be officially sent
in those mailing lists and discussed.

You can have an overview of the API
here:https://wiki.mozilla.org/WebAPI/WebActivities

Web Activities' intent is not to be a clone of Google's Web Intents with
some naming and API details changed. Web Activities aim to be a simple
API trying to solve a very clear set of use cases.

It has been a bit hard to judge the desired scope of Web Intents. People
have suggested that Intents should be able to solve everything from
getting low-level Sensor information [1] to the ability to implement
services like Push Notifications [2] to doing discovery and control of
DVR hardware from the browser [3]. It is unclear if this is just a list
of things people wish that Intents could help with, or if these are hard
requirements that the spec authors are using to design the spec for.

An API which allows building a wide range of applications is generally a
good API, however it is also important to have a concrete set of use
cases when designing an API to make sure that it solves those use cases
well. Our concern is that Intents are designed to solve the ambigious
use case of "communicating with anything".

As a reminder, the basic use cases of Web Intents seem to be: "Users use
many different services on the web to handle their day to day tasks,
such as sharing images, editing documents and listening to music. They
expect their applications to be connected and to work together
seamlessly." [4] and the basic actions/intents/activities the API
mentions are "share, edit, view, pick" [4].

The current shape of Web Intents seems to allow consumers of the API to
use it for:
1. Delegating: an application delegates an activity to another application.
2. Discovery: some consumers seem to be inclined to use Web Intents to
discover other services. This is what Bryan Sullivan suggested for the
Push Notification API. When the Intent is invoked no action would
actually be taken, instead a URL is returned and then it's up to the
page to communicate with that URL with the Web Intent API no longer
involved.
3. Communication: you can use Web Intents to simply create a channel of
communication between APP A and APP B: you can easily specify which
service should be used to handle the intent and then, you can
communicate with it.

We believe we should restrain the API to (1).

(2) is something that is better done with a separate Discovery API since
the model here is very different. It is no longer transparent to the two
parties involved who they are communicating with, and the UA no longer
has the ability to mediate the communication.

(3) is something that can be solved with already existing parts of the
platform, like MessageChannel or WebSockets.

The main issue we see with trying to solve all those use cases in one
API is regarding implementation and especially UI. The way we see it,
when an application wants to start an activity/intent, a UI should show
the list of applications able to handle it, and it should be clear to
the user that this application will be used to complete the action
he/she intended to do. For example, if the user clicks on the "camera"
button, a UI will ask him/her which application should be used to
pick/take a picture.
If you try to mix (2) and (3) in here, you will have serious problems
like an application initializing a communication channel with another
application at startup: the user might see a UI asking him/her to chose
an application in the list but will have no idea why and for what. This
could apply for the Push Notification case: the UA cannot know that the
intent/activity was sent to discover a push service instead of
delegating an activity to it. Actually, for security purposes, we are
even going to limit activities so they can be started only when
generated from a user action.

Basically, we think Web Activity should be a very simple API that allows
an application to delegate an activity to another application with very
clear rules regarding starting the activity, handling it and the UI
in-between.
Another simple API could be used to do (2) and (3). Basically, you can
imagine an API that would allow you to discover a service doing "foo"
and if the service agrees, both parts will get a MessageChannel port
they can use to communicate with each other. This API is out of scope of
Web Activites but might be helpful for applications that want to
discover services and communicate with them in the background.

So, we would like to suggest, if Google agrees, to work together on a
common version of that API that would be restricted to the use cases we
mentioned. It could be based on Web Activities (or Web Intents stripped
from all unnecessary stuff). We are willing to discuss any detail of the
API as long as we do not include any feature we believe are out of scope.

[1] http://lists.w3.org/Archives/Public/public-device-apis/2012Mar/0182.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0860.html
[3] http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents
[4] http://webintents.org/

Cheers,
--
Mounir

Received on Tuesday, 12 June 2012 14:09:19 UTC