CfC: Publish FPWD of Web Intents spec; deadline June 12
Dave Raggett (d...@w3.org) made a call [1] on April 10 to publish a first public working draft, and this is a Call for Consensus to do so, using the following document as the basis: dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html I included public-webapps and public-device-apis on this CfC since Web Intents is a joint-deliverable [2][3] between these two groups. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does not necessarily mean there is consensus on the spec's contents. Positive response to this CfC is preferred and encouraged and silence will be considered as agreement with the proposal. The deadline for comments is June 12. Please send all comments to: public-web-inte...@w3.org Thanks, James Hawkins [1] http://lists.w3.org/Archives/Public/public-web-intents/2012Apr/0016.html [2] http://www.w3.org/2012/webapps/charter/ [3] http://www.w3.org/2011/07/DeviceAPICharter
Re: Web Intents on WebApps' May 1-2 f2f meeting agenda?
Great, thanks! On Tue, Apr 10, 2012 at 5:30 PM, Arthur Barstow art.bars...@nokia.comwrote: On Apr 10, 2012, at 2:28 PM, ext James Hawkins wrote: If we can schedule this for May 1, that would be fantastic. Unfortunately something last-minute has come up and I won't be able to attend May 2. I put Web Intents in the 1:30 to 2:30 slot on Tuesday May 1 http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting#Agenda_May_1. If that doesn't work, let me know. -Thanks, Art Thanks, James On Tue, Apr 10, 2012 at 5:00 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi James, Greg, All - in case you did not know, WebApps is having a f2f meeting May 1-2 in Mountain View (logistical details below). Given Web Intents is a joint deliverable with WebApps, perhaps it would be useful to allocate some agenda time for Web Intents e.g. an update on the status, plans, etc. If we do want to allocate some time, we can of course use the W3C voice conference bridge to facilitate remote participants but we would need to nail down the day + time slot. WDYT? -AB=
Re: Web Intents on WebApps' May 1-2 f2f meeting agenda?
If we can schedule this for May 1, that would be fantastic. Unfortunately something last-minute has come up and I won't be able to attend May 2. Thanks, James On Tue, Apr 10, 2012 at 5:00 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi James, Greg, All - in case you did not know, WebApps is having a f2f meeting May 1-2 in Mountain View (logistical details below). Given Web Intents is a joint deliverable with WebApps, perhaps it would be useful to allocate some agenda time for Web Intents e.g. an update on the status, plans, etc. If we do want to allocate some time, we can of course use the W3C voice conference bridge to facilitate remote participants but we would need to nail down the day + time slot. WDYT? -AB Begin forwarded message: *Resent-From: *public-webapps@w3.org *From: *ext Arthur Barstow art.bars...@nokia.com *Date: *April 9, 2012 9:40:28 AM EDT *To: *public-webapps public-webapps@w3.org *Subject: **Reminder: May 1-2 f2f meeting: registration deadline is April 16* *archived-at: * http://www.w3.org/mid/046aa975-d33f-4b99-9b57-13c0739e7...@nokia.com Reminder: April 16 is the deadline to register for WebApps' May 1-2 f2f meeting http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting. Please send agenda topic proposals to the list or add them to the meeting page http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting. -Thanks, AB Begin forwarded message: *Resent-From: *public-webapps@w3.org *From: *ext Arthur Barstow art.bars...@nokia.com *Date: *March 15, 2012 8:13:54 AM EDT *To: *public-webapps public-webapps@w3.org *Subject: **Call for Agenda Topics: May 1-2 f2f meeting; Registration deadline April 16* *archived-at: *http://www.w3.org/mid/4f61dd02.2000...@nokia.com Hi All, I created a meeting page for our May 1-2 f2f meeting at a Microsoft facility in the Silicon Valley http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting. Participants must register for this meeting via https://www.w3.org/2002/09/wbs/1/webappshtml-s2012--meeting/ and the deadline for registration is April 16. As we have done with our previous f2f meetings, I propose a mixture of pre-determined topics and topics agreed at the meeting. As such, please consider this as a call for agenda topics and if so desired, include a proposed day + time slot for the topic. Since WebApps' revised charter http://www.w3.org/2012/03/webapps-proposed-charter.html should be formally approved by the meeting, I think we should consider all of our new specs as potential candidates for agenda topics. -Thanks, ArtB
Re: April face-to-face meetings for WebApps
On Tue, Feb 7, 2012 at 4:17 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Feb 7, 2012 at 9:28 AM, Dimitri Glazkov dglaz...@google.comwrote: On Tue, Feb 7, 2012 at 5:34 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 07 Feb 2012 13:55:59 +0100, Arthur Barstow art.bars...@nokia.com wrote: I am especially interested in whether Editors and Test Facilitators/Contributors will attend. Highly likely I'll attend. Me too. Same. Ditto.
Re: [Web Intents] Task Force Mailing List set up
+cc:public-webintents -bcc:public-webapps -bcc:public-device-apis We'll have a wiki, though we're still working out the details on that end; it's particularly rough right now during the US holidays. I'll make sure to get back to the public-webintents list once the wiki and group are set up properly. For now I'm very keen to hear your ideas, and I think the public-webintents ML is a fine place to hash out your thoughts. Thanks, James On Mon, Nov 21, 2011 at 6:03 AM, Giuseppe Pascale giusep...@opera.comwrote: Great, thanks for moving this forward. Question: are we going to have also a wiki or will we re-use one of the wiki from dap and/or web-apps? I'm trying to flash out some thoughts around home discovery VS web intents and a wiki is a simple tool to outline some ideas. /g On Fri, 18 Nov 2011 18:05:46 +0100, James Hawkins jhawk...@google.com wrote: The Web Intents Task Force is starting to take shape! If you'd like to be a part of shaping this API, please involve yourself by joining the new mailing list. A W3C mailing list has been set up: http://lists.w3.org/Archives/**Public/public-web-intents/http://lists.w3.org/Archives/Public/public-web-intents/ To subscribe to this mailing list, send an email to public-web-intents-request@w3.**org public-web-intents-requ...@w3.orgwith the subject 'subscribe'. We've created a group for the TF: http://www.w3.org/2000/09/**dbwg/details?group=50861**public=1http://www.w3.org/2000/09/dbwg/details?group=50861public=1, though it's just a placeholder for now since the logistics of the group have not been worked out completely yet. I'll let you know once I know more. I'm in the process of uploading the draft of the API to w3.org; I'll send a message to public-web-intents once that's complete. Thanks, James -- Giuseppe Pascale TV Connected Devices Opera Software
[Web Intents] Task Force Mailing List set up
The Web Intents Task Force is starting to take shape! If you'd like to be a part of shaping this API, please involve yourself by joining the new mailing list. A W3C mailing list has been set up: http://lists.w3.org/Archives/Public/public-web-intents/ To subscribe to this mailing list, send an email to public-web-intents-requ...@w3.org with the subject 'subscribe'. We've created a group for the TF: http://www.w3.org/2000/09/dbwg/details?group=50861public=1, though it's just a placeholder for now since the logistics of the group have not been worked out completely yet. I'll let you know once I know more. I'm in the process of uploading the draft of the API to w3.org; I'll send a message to public-web-intents once that's complete. Thanks, James
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). What use cases are you envisioning will require progress events? Thanks, James On Mon, Nov 14, 2011 at 7:30 PM, Charles Pritchard ch...@jumis.com wrote: So, to make things difficult again -- how do we monitor progress? When I'm saving to the cloud, I want my XHR onprogress. I don't need high-fidelity progress events -- they don't even make sense when one server is copying to another, but I do need something, otherwise we're back in the dark ages of polling on a separate channel. This is an area where a MessageChannel could be handy; even an EventSource would work out, though it feels a little awkward. It's only one way, which is all that's needed, so maybe it's the right place to be looking. http://dev.w3.org/html5/eventsource/ -Charles On 11/13/11 3:24 PM, Paul Kinlan wrote: On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard ch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
http://usecases.webintents.org/ Though admittedly it's not complete, and we need to update the site with a list of use cases we've rejected. On Tue, Nov 15, 2011 at 11:30 AM, Josh Soref jso...@rim.com wrote: James wrote: A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). Is it possible to get your UCs published somewhere? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
Since we don't have background intents (many reasons why, though we looked into the idea), the service is responsible for displaying progress UI for this use case. For example imagine the service is Dropbox: the client initiates the upload action and Dropbox is selected as the service by the user. Likely Dropbox will use an inline disposition. The picker will be open showing the service until the operation is complete. Dropbox should show the upload progress UI in their UI in this case. Does that work in your mind? I'm not attempting to put the kibosh on this line of thought; I'm very open to any use cases where progression notifications to the client are necessary for a good UX. James On Tue, Nov 15, 2011 at 11:15 AM, Charles Pritchard ch...@jumis.com wrote: I may be misunderstanding things, but I was thinking that saving a file to the cloud. FileSaver and XHR have onprogress events so users don't wonder too-much about large file uploads. Those are the only cases I was thinking of. -Charles On 11/15/2011 10:31 AM, James Hawkins wrote: A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). What use cases are you envisioning will require progress events? Thanks, James On Mon, Nov 14, 2011 at 7:30 PM, Charles Pritchardch...@jumis.com wrote: So, to make things difficult again -- how do we monitor progress? When I'm saving to the cloud, I want my XHR onprogress. I don't need high-fidelity progress events -- they don't even make sense when one server is copying to another, but I do need something, otherwise we're back in the dark ages of polling on a separate channel. This is an area where a MessageChannel could be handy; even an EventSource would work out, though it feels a little awkward. It's only one way, which is all that's needed, so maybe it's the right place to be looking. http://dev.w3.org/html5/eventsource/ -Charles On 11/13/11 3:24 PM, Paul Kinlan wrote: On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchardch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
Re: [DRAFT] Web Intents Task Force Charter
On Thu, Nov 10, 2011 at 5:54 AM, Robin Berjon ro...@berjon.com wrote: Hi all, here is a draft of the Intents joint Task Force charter for comments from WebApps and Device APIs. A TF charter is nothing formal and requires no overhead — it can live as an email in a mailing list, it just documents the existence of the TF, and gives a few indications as to how it works. I've added some notes below about the points that may be contentious. If no one screams bloody murder by Monday I'll ask the Team to set things up. It's short but we've discussed this together last week, and DAP intends (no pun, err, intended) to rely rather heavily on Intents so we'd rather move fast rather than wait for WebApps to recharter, which could take a few months. The Web Intents Task Force works on a joint deliverable of the WebApps and Device APIs WGs that aims to produce a way for web applications to register themselves as handlers for services, and for other web applications to interact with these through simple requests brokered by the user agent (a system commonly known as Intents, or Activities). The mailing list on which the TF's discussions take place is public-inte...@w3.org. The chair is Robin Berjon. Operational modalities such as whether or not to have phone and/or face to face meetings, as well as where to store the draft document are left to the TF to decide for itself. Decisions are made by consensus inside of the task force and do not require separate ratification by the wider groups. It is important to note that until such a time as the WebApps WG is rechartered with Intents in its list of deliverables, it will be necessary for participants in WebApps who are not in Device APIs and wish to make substantive contributions (just joining the discussion and providing comments is always fine) to make an RF commitment for this deliverable (not necessarily for other DAP deliverables, naturally). For more details on this, please contact the W3C Team. ISSUES: • The description isn't terribly precise, but I think it works • As I've said before, I am only putting myself forward as chair because so far no one else stepped up. I don't mind doing it, but I equally don't mind letting someone else do it. I don't expect it to be a very demanding position. WDYT? Sounds good. I have a vested interest in the success of Web Intents, so I would be happy to Chair the TF if you don't mind, Robin. I'm looking forward to getting the discussions rolling. Thanks, James
Re: Consolidating charter changes
Under 'Additions Agreed': * Web Intents - this will be a joint deliverable with DAPI WG Pedantically, not politically: My recollection is that the agreement was only to add Web Intents to the Webapps charter (neither accepting nor denying a joint deliverable with DAPI). The status of the joint deliverable is still a possibility, just technically not agreed upon as of yet. It may be best to reword this to state that the possibility still exists, so those not in attendance don't get the idea that we agreed to a joint deliverable at the meeting. Thanks, James On Tue, Nov 8, 2011 at 9:37 AM, Arthur Barstow art.bars...@nokia.comwrote: During the October 31 meeting, we discussed [1] various additions, changes and deletions for WebApps' current charter [2]. To consolidate the various proposals, I created the following doc: http://www.w3.org/2008/**webapps/wiki/CharterChangeshttp://www.w3.org/2008/webapps/wiki/CharterChanges My expectation is that Doug will this information when he drafts our updated charter. Comments on this doc and our future charter welcome. However, if we are going to add any new deliverables, I think there should be broad agreement on the spec, including prior commitment to drive the spec through all of the phases of the process including testing and implementations. Chaals, IanF - I included some actions/questions for you (mostly recorded at the f2f meeting). -AB [1] http://www.w3.org/2011/10/31-**webapps-minutes.htmlhttp://www.w3.org/2011/10/31-webapps-minutes.html [2] http://www.w3.org/2010/**webapps/charter/http://www.w3.org/2010/webapps/charter/
Re: We just ran out of time ... [Was: Re: Component Model f2f: Actionable things]
Agreed. What little time we did have was quite productive, and getting to know non-Google WG members outside of a work context was extremely helpful for me. James On Thu, Nov 3, 2011 at 11:08 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: Meeting more frequently is something that appeals to me greatly. Email discussions (or worse IRC banter) are not as productive. :DG On Wed, Nov 2, 2011 at 9:38 PM, Arthur Barstow art.bars...@nokia.com wrote: On 11/2/11 6:41 PM, ext Dimitri Glazkov wrote: You can see the minutes here: http://www.w3.org/2011/11/02-webapps-minutes.html Thanks Dimitri. First of all, thank you all for coming and participating. That goes for me and Chaals too re Monday and Tuesday! It was exhausting, and we just ran out of time. Stupid time! Well, we may get together more frequently than just the annual TPAC meeting week. If folks think that would be useful (e.g. in 6 months), please speak up and we can take it from there. Otherwise, WebApps' next f2f meeting is during the 2012 TPAC meeting in Lyon, FR Oct 29 - Nov 2. -AB
Re: Adding Web Intents to the Webapps WG deliverables
Hey Ian, comments in-line. On Thu, Sep 22, 2011 at 2:36 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 21 Sep 2011, Paul Kinlan wrote: On Tue, 20 Sep 2011, Paul Kinlan wrote: Q: Why are the verbs URLs? Verbs don't have to be URL's but a URL will allow us a point of reference to documentation, versioning and namespacing allowing verbs with similar names but by a different provider to not conflict with each other (thus allowing developers to come up with their own schemes and APIs outside of standardisation). If they're just arbitrary strings, this should be made clearer. We will strongly encourage a URL, so we might have to say it must be a URI to make developers think of that first. A URL gives us a lot of advantages (more below on your sharing point). Q: Why are some verbs hard-coded into the API? Convenience and ensuring there is a consistent use of the first set of intents that cover the most common initial use cases. If the strings are inconvenient enough that you feel the need to provide a constant for them, maybe that's a sign that the strings should be changed! Rather than 'http://webintents.org/share', why not just 'share' for the share intent, for example? Providing a single verb will vastly increase the chances that of collision of competing providers saying they handle the action but provide a completely different API. There's no difference between two people coming up with the name foo and two people coming up with the name http://webintents.org/foo;, unless you're saying you're confident that people won't use the prefix the spec uses for its verbs for their verbs. But this is a non-problem. In practice, we have plenty of examples of spaces where conflicts don't happen despite not having used long names such as URLs. For example: - rel= values in HTML - element names in HTML - MIME type names - scheme names We are following the model set by Android Intents by bootstrapping the feature with a list of actions that we agree will be far-reaching and useful, e.g., share, pick, edit, save. The Android Intents system employs java-style namespacing, e.g., android.intent.action.EDIT is the string value of the ACTION_EDIT constant. The idea is that vendors can add to the intent ecosystem by creating new actions, usually by setting the namespace appropriately, e.g., org.openintents.action.CALCULATOR. When designing the format of the Web Intents action string, we got a lot of feedback that the java namespacing is not native to the web and that URLS would be a better namespacing scheme. This gave us the added benefit that, by setting precedence with the default list actions, action URLs serve both as a namespace mechanism and the page at the URL contains documentation for the particular action. If a developer wants to find out more about http://webintents.org/share, all she has to do is visit that URL (try it!). If, for example, Twitter decided to add a new action, say 'tweet', they could set the action string to http://dev.twitter.com/tweet which would contain the input/output specification for this action. A verb on its own will imply that it is a web intents verb managed by the webintents project and all the documentation for that will live under webintents, which means we would then need to think about standardisation and stewardship for the entire namespace. I don't see why. Just have a wiki page that people can list their verbs on and then point to their documentation. We plan to employ a model such as this. openintents.org currently lists third-party intents for the Android system, though we could use that site to enumerate Web Intents. Android is a good example, the intent system is fabulous, if you look at http://www.openintents.org/en/intentstable most developers end up reverse name-spacing the intent and I believe when people want to namespace their API they will either use this syntax or some other inconsistent naming. Having a URL is nice and consistent with the web. I think having a URL is very _in_consistent with the Web. Few technologies use URLs for verbs, and most of them have gone nowhere fast. URLs are Web pages. Authors find it confusing when they are used for other things. I'm not saying to actually use navigator.registerContentHandler and navigator.registerProtocolHandler, but why not base something on that API rather than reinventing the wheel? We have two bits, one is registering the intent which we think is better declaratively (explain more later in the email) and the second is the invocation which we believe WI has a far simpler usage of the API and can take advantage of postMessage. I disagree that what you have is as simple as what you could have. In particular, what you have is definitely not as simple (nor as powerful) as the proposal I put at the end of my e-mail, for instance. Specifically
Re: Adding Web Intents to the Webapps WG deliverables
Hi Robin, On Tue, Sep 20, 2011 at 7:55 AM, Robin Berjon ro...@berjon.com wrote: Hi Ian! On Sep 20, 2011, at 16:26 , Ian Fette (イアンフェッティ) wrote: I don't get it. The overhead of getting all the other browsers to join the WG you mention is just as high Can you please detail what overhead that involves? There are only two cases here: * You have IP concerns relevant to Web Intents. In that case you need IP portfolio review. That overhead is the same for joining and for rechartering an existing group (it's just politically higher in the rechartering case). * You don't have IP concerns relevant to Web Intents. In that case you just join the group ― zero overhead. It's a simple solution that just involves clicking through a form. If you have a political mexican standoff of vendors not joining while the others aren't, it can hardly be blamed on the process, DAP, WebApps, W3C, or whatever else. I'm sure that it can be sorted out, though. Intents were initially added to DAP's charter in good part because Google asked us to. It's a little annoying to be blamed for doing exactly what you were asked to do. I'm the TL of the Intents team at Google, but this is a large company and I've only been involved with the larger Open Web Platform team for ~6 months. I'm not familiar with the details surrounding Google asking DAP to add Intents to the charter. Can you fill me in on the details? To clarify on my end, the current draft of the Web Intents API is entering a cluttered namespace; there are several proposals with similar names/ideas that are not directly tied to this API: * Web Introducer/Web-send (Tyler Close, published early 2010) * Web Intents (Paul Kinlan, published in Nov 2010) If my hunch is right, you're referring to Tyler's Introducer proposal; note that while Tyler does work at Google, his work on Introducer was not tied to the Chrome team. The Web Intents proposal of this thread has the backing of the Chrome team which has agreed that Intents is the way to move forward in this problem space. Thanks, James
Re: Adding Web Intents to the Webapps WG deliverables
+Paul Kinlan, Greg Billock - from Google team. +Mike Hanson, Ben Adida - from Mozilla team. On Mon, Sep 19, 2011 at 9:25 PM, Charles Pritchard ch...@jumis.com wrote: Should Paul Kinlan be Cc'd on this? His concept work is helpful. On Sep 19, 2011, at 8:53 PM, Ian Hickson i...@hixie.ch wrote: Why not just improve both navigator.registerContentHandler and navigator.registerProtocolHandler? In particular, why are intents registered via a new HTML element rather than an API? How do you unregister? How do you determine if the intent was registered or not? How do you conditionally register (e.g. once the user has paid for the service)? How does an already-open page get to handle an action? e.g. say GMail wants to handle the share intent, and the user already has GMail open, and the user clicks a share button on Flickr. How does the existing GMail instance get the notification? Why are the verbs URLs? Why are some verbs hard-coded into the API? How are types matched? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Adding Web Intents to the Webapps WG deliverables
I am the tech lead for the team designing and implementing Web Intents [1] for Chrome at Google. Web Intents is a web platform feature modeled after the similarly named feature in Android OS. Web Intents enables client sites to request high-level functionality, e.g. share, edit, pick, upload, auth, from an unknown (to the client) provider. The UA enumerates the list of registered providers that the user has already accepted as Intent handlers, allowing the user to pick which provider she wants to use for the particular action. This feature is not a panacea, nor do we envision it as a 'meta API'; however, the use cases we've focused on will make web apps much more connected and useful for users. Take the NASCAR problem: with Web Intents, publishers can get rid of maintaining an ever-growing list of 'share' providers, replacing them with one share button that kicks off the 'share' action. The user only sees the sites that she actively uses. Note: we're actively working with Mozilla on the API, and the draft I have prepared has been agreed upon by both vendors. I've read through the Webapps charter, and I believe Web Intents fits the goals and scope of the WG. Goals * Promote universal access to Web applications across a wide range of devices. - Web Intents can be implemented in browsers on all devices, and more importantly, the feature is a perfect conduit for hooking into platform functionality (Android Intents, iOS API, a scalable registerProtocolHandler). * Promote creation of tutorials and other educational material. - Check out http://examples.webintents.org where we have example clients/providers of Web Intents using a JS shim that works across all current browsers. - The action string in the API is suggested to be a URL pointing to documentation for the action, e.g., http://webintents.org/share is both the string for the 'share' action and the URL of the documentation for said action. Scope * Markup vocabularies for describing and controlling client-side application behavior. - Web Intents provides an intent tag that allows provider sites to declare which intent actions they handle. * Programming interfaces for client-side development: platform interaction. - As stated above, this feature can easily be extended to hook into the platform to, say, allow the UA to notify providers of platform events or data sources, e.g., plugging in a camera. The developers of this API, from both Mozilla and Google, believe Webapps is the right home for Web Intents. I'd like to open discussion on the topic and get your feedback. Ultimately we'd like to take the next steps towards getting Web Intents officially out in the open, actively developed by the larger Webapps community. Thanks, James Hawkins [1] http://dev.chromium.org/developers/design-documents/webintentsapi
