W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2011

Re: [DRAFT] Web Intents Task Force Charter

From: Rich Tibbett <richt@opera.com>
Date: Thu, 10 Nov 2011 16:27:34 +0100
Message-ID: <4EBBED66.1030107@opera.com>
To: Robin Berjon <robin@berjon.com>
CC: public-webapps Group WG <public-webapps@w3.org>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Hi Robin, all,

Robin Berjon 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-intents@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.
> """
>     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.

Opera would like to explore Local Device and Local Network Discovery as 
a subset of Web Intents. At this point, having studied the Web Intents 
proposal, we're unclear how this would work considering that:

a.) to register a URL endpoint as an intent provider the user must visit 
a web page (presumably hosted by the target device itself) and capture 
the intent registration from that page before that intent provider can 
be used within the UA.
 >> WHAT WE ACTUALLY WANT: to enable auto-discovery and 
auto-registration of local device services and locally networked device 
services to the point that the user doesn't need to go out and register 
local devices and services upfront. When a user requests a particular 
service, they can then directly choose a device that implements the 
requested service rather than having to go through the indirection of 
searching out, navigating to and registering each intent provider first.

b.) to then subsequently use a registered intent provider the concept is 
to open that provider, again as a web page in a seperate tab within the 
UA. From here we can then establish a bi-directional web messaging 
channel on which we can send and receive messages to communicate to and 
from that web page that is representing the current local service.
 >> WHAT WE ACTUALLY WANT: to communicate transparently with a 
locally-connected service (after user authorization has been 
established), without requiring that service to manifest itself as a web 
page in a new browser tab. We'd also like to speak the protocol (web 
sockets, http, etc) that the device currently supports.

My assumptions on Web Intents above may be incorrect. I'd appreciate 
some clarification if this is the case.

Perhaps someone could take the time to describe exactly how a user could 
communicate with an existing TV device in their home from a web browser 
supporting web intents based on the above requirements?

br/ Rich
Received on Thursday, 10 November 2011 15:28:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:32 UTC