Re: [DRAFT] Web Intents Task Force Charter

+1 Rich's comments. We're interested in determining if Web Intents can
implement the discovery requirements of existing protocols and devices.

-Clarke

On 11/10/11 8:27 AM, "Rich Tibbett" <richt@opera.com> wrote:

>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.
>> """
>>
>>
>> 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?
>>
>
>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 16:00:18 UTC