Re: Web Activities: counter-proposal to Web Intents
On Tue, 12 Jun 2012, 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 I've taken this proposal and the Web Intents proposal (amongst others) and written up a proposal that attempts to merge them here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/036719.html If anyone has any feedback on that, please e-mail the WHATWG list. (For background: The editors of the Web Intents draft suggested a few months back that I spec such a thing in the HTML spec, superceding their work and integrating it with the register*Handler() methods.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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 mou...@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
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
Re: Web Activities: counter-proposal to Web Intents
On 12/6/12 16:08 , Mounir Lamouri wrote: 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. JCD: Web intents does not provide discovery, but more like a directory service. Your proposal also provides registration and a sort of directory service, even if you do not provide a matching algorithm. So your proposal is more or less at the same level of functionality than web intents in this respect. 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. JCD: Web Intents also provides some isolation between the client and the service. Are you providing this isolation too ? If your APP A and B can later establish a communication channel, it seems not. Yet that is a very appealing feature. Best regards JC -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
