Re: Web Activities: counter-proposal to Web Intents

Thanks, Mounir. I've been reading the overview, and I have a lot of
the same reactions Robin did to issues of scope. Based on what I read
in the wiki and in this mail, the scope you have in mind is very
similar to where I think we all agree the use cases of web intents
predominately lie (edit, pick, share, view).

The approaches of the APIs (RPC-style as opposed to mediated through
postMessage, for example) are very similar. The mechanisms they use
are are also functionally very similar: there's registration, there's
invocation, there's delivery, there's response. I see an open action
and type namespace, so that web developers are free to take advantage
of the functionality to do things that we can't predict currently, and
yes, so that other standards can use the functionality as a mechanism,
in the same way it uses things like structured clone and eventing.

All this makes me believe we have a very similar understanding of this
problem and what is entailed in a responsive solution. I am optimistic
that we'll figure out the technical details and come to consensus
about the right API to expose this functionality to web developers.


Moving to specifics of the API, I find a lot to like in this proposal.

Invocation by scope closing is unintuitive, but using a Future-style
object is appealing. That is, something like this:

var futureValue = navigator.startActivity(intent payload);
futureValue.onReply = handler;
futureValue.onError = handler;

In Web Intents, we used callbacks for this mechanism, since it ends up
being more compact and also more idiomatic for web APIs. Still,
IndexedDB makes good use of the Future style, and so do many popular
JS libraries. One might wish the File/Filesystem API had taken a
similar approach.

The differences in service and intent parameters are mostly cosmetic.
One excellent solution I found there to a longstanding problem, which
we should adopt, is to include a "multiple=true" extras parameter to
indicate that the client can handle (and therefore, that the service
can produce), arrays of values in the return type.

For delivery, I think utilizing a novel system message handler is less
desirable than other evented mechanisms for delivery. There are a
couple such that we should consider, however. When originally
proposed, we specifically wanted to rule out multiple delivery to a
particular context, which led us to the very simple "window.intent"
mechanism. Our thinking now is that ruling this out is a mistake, and
we need to provide a mechanism to deliver the intent payload as an
event. I think the most unsurprising way to do this would be a
window-based "intent" event. Another suggestion which Alex Russell
made, and I think is really slick, is to deliver to an intent listener
on the <intent> tag itself. This couples registration and handling in
a very compelling fashion.

For registration, I think Ian Hickson's proposal to consider web
intents, registerProtocolHandler, and registerContentHandler, as all
part of the same feature is the right direction. I prefer declarative
to imperative registration, as I think it apportions responsibilities
more cleanly and accurately, but it looks like at the end of the day
we'll have both, and for good reasons.



On Tue, Jun 12, 2012 at 7:08 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> 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.

See [5]. We're in agreement about this being important.

>
> 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.

Just to clarify what I think you mean here, I don't think any of us
regard the W3C standards process as two-party talks. We're working
towards a common set of goals, and everyone involved is welcome to
participate. Instead, I'd prefer to read this as an offer to help with
editing work on the spec itself, which would be much appreciated!



>
> [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
>


[5] http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#methods-1

Received on Thursday, 21 June 2012 16:24:55 UTC