Re: Web Activities: counter-proposal to Web Intents

[removing cross-post]

Hi Mounir,

On Jun 12, 2012, at 16:08 , Mounir Lamouri wrote:
> 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

Thanks for putting this together.

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

I don't think that it's entirely fair to criticise the Intents spec based on what a bunch of other people have been saying they'd like to see it do.

For what it's worth, in my experience, a lot of the time when people say "we could use Intents" for this they mean to say that they could use Intents as the connector part. So if your sensor has a small HTTP server, you can grab a service page off it, and it will know how to communicate with the sensor's proprietary protocol. Starting the corresponding activity would then allow the user to pick the desired sensor(s) and the app to use it. Any discovery that might make that sensor automatically available would be provided by another specification (but the model is such that it would integrate nicely).

Likewise, what I understand when I read Bryan talking about using Intents to "discover" the Push service is that the user would select that service from the usual Intents selection dialog — in other words, the user is the discovery broker, not some magic.

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

Can you point at specific parts of the draft that sustain this concern? It's a lot easier to entertain an alternative proposal based on technical objections than on vague concerns.

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

We're agreed on (2), but then again it's not something that Intents does so you seem to be fighting a strawman. The draft does use the term "discovery" but not in the sense that you mean and that would be encompassed by a Discovery API (e.g. of the type that Opera has been proposing). Discovery as per intents is essentially remembering services with <intent> registrations and relying on the user as a broker to plug those to a requesting application. That's a very limited sense, and a very useful one too. As far as I can tell it's exactly what you're doing with registerActivityHandler(), no?

As for (3), I don't really understand how you could communicate with a client-side page using WebSockets — I take it you mean client-server communication here? An intent exposing a service could very well use WebSockets to communicate with some backend of its own if it wanted to. Regarding MessageChannel, the current Intents spec allows for the exchange of MessagePorts — it is basically providing a way of plugging the posting of messages from arbitrary, user-discovered sources. So here too it feels like your objecting to something that just isn't there. What am I missing?

I get a sense that the primary difference between Activities and Intents (that doesn't mostly boil down to syntax) is that with the former you can make a request and get a reply just the once, whereas with the latter you can do that but also keep the channel open for more postMessage() interactions. I don't really understand how this limitation is beneficial. It doesn't affect complexity much (if you've poked a hole in the wall, you might as well keep it open) and it's damn useful.

Perhaps I'm missing something? I think that it may prove useful to show examples of how a few common uses would work.

For instance, one thing that isn't clear to me (reading a spec that normatively references forum messages isn't always easy) is whether you can keep a reference to the ActivityRequestHandler and call postResult() more than once? A good example where this is needed is if you want to implement Geolocation's watchPosition() using Intents/Activities (that would make for a good item in a list of comparative examples).

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

I think you're mixing quite a few things here, but there is nothing that prevents Intents from being triggered solely on user action too (we actually discussed that in Shenzhen). Paragraph 2 in the Introduction says "An Intent is a user-initiated action delegated to be performed by a service". Obviously, though, that should be eventually left to the UA to decide.

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

I'm all for more participants to the fun party we're having here, but I see two issues with the suggestion in this paragraph:

1) You want an API limited to the use cases you've mentioned — but you haven't mentioned any use cases!
2) You're asking to restrict the scope based on descriptions of Web Intents that seem to originate more in the hype than in the spec. That's hardly actionable.

So I would like to make a counter-suggestion:

1) please provide the use cases you have in mind but did not write down;
2) please detail which parts of the current specification you would like to drop or change (substantially, not on syntax);
3) please clarify whether it's possible to get multiple postResults().

Thanks!

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Wednesday, 20 June 2012 13:15:42 UTC