Re: Updated draft charter

Nilsson, Claes1 wrote:
> Hi,
>
> As requested I will try to provide input on the stated deliverable: "An “intent”-based mechanism to trigger the launch of applications".
>
> Looking at the existing proposals Web Introducer and Web Intents:
>
> * Web Intents (http://webintents.appspot.com/ ): Similar to Android intents but for web applications. This means that a web application could register itself to be a "service" that handles certain "intents". An example is a media player implemented as a web application that registers itself to process certain media types. So when you click on a media file this web media player is activated.
>
> * Web Introducer (http://web-send.org/ ): The Web Introducer focuses more on allowing web application to access and interact with the user's personal resources, e.g. user's social networking site account or the user's media resources. Each resource is accessed through a provider, that is a web page interacting with the requesting web application. Users register the providers, that handle certain data types, they want to make available to web applications. An example is allowing a user share link (a "bookmark") to a news article with a social networking site selected by the user (http://web-send.org/bookmark/  ). The provider in this example handles the "bookmark" data type.
>
> There are differences but also similarities between the concepts and it seems as the "Web Intents" proposal has been merged with Web Introducer (See http://paul.kinlan.me/?c=1 ).
>
> So what do we want to achieve in DAP?
>
> I would say:
> * The possibility for web applications to register themselves as handlers/providers for certain data types

If we took a strict definition of 'data type' isn't this already covered 
in [1]?

> * The possibility for web applications to request access to a handler/provider of a certain data type

Again, 'data type' seems to be the wrong terminology. It's really best 
labeled as an intent IMO.

> * The possibility to create a secure and anonymous communication session between the requesting web application and the handler/provider web application.
>
> Sorry for this long elaboration :-) In the charter it should be one sentence. So what about?
>
> "An API that allows web applications to register themselves as handlers/providers for certain data types and an API that
> enables other web applications to discover these handlers/providers and gain permission to interact with them."
>

In the proposed charter text above I'd much prefer to stick to instead 
calling a 'data type' an 'intent' to avoid confusion.

On another note, I see some potential here for a Discovery API (as added 
to the charter already) to report service intents supported by other 
local devices. Then to be able to register those intents in the api 
proposal above. Then to allow a web page to request access to those 
services, then establish the full-duplex communication channel provided 
by Web Send to those devices and communicate according to a specific 
Service-based API. Effectively, we should aim to make discovery, 
registration and invocation in to a web tool-chain where one can feed 
and reuse the other.

- Rich

[1] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers

> Best regards
>    Claes
>
>
>
>> -----Original Message-----
>> From: public-device-apis-request@w3.org [mailto:public-device-apis-
>> request@w3.org] On Behalf Of Dominique Hazael-Massieux
>> Sent: den 6 april 2011 10:33
>> To: public-device-apis@w3.org
>> Subject: Updated draft charter
>>
>> Hi,
>>
>> I've updated the proposed new charter for the group with the results of
>> the discussions at our F2F:
>> http://www.w3.org/2010/11/DeviceAPICharter.html
>>
>> In particular, I have:
>> * removed the comm log api
>> * split the APIs for beeps, vibrations and menu
>> * added the permission API
>> * added the WG note re privacy best practices
>> * changed app launcher into our discussion of an intent-based mechanism
>> * added device and services discovery
>> * split sysinfo in network, battery, generic sensors
>> * amended success criteria to mention installable Web applications
>>
>> I think the intent-based mechanism would deserve a bit more
>> explanation;
>> I'm hoping Claes could provide that.
>>
>> I haven't added the Rec-track privacy deliverable: Frederick, could you
>> provide some rough description of what should be in the charter?
>>
>> I think I have integrated all the other points that were discussed, but
>> please let me know if I missed something.
>>
>> Dom
>>
>>
>

Received on Friday, 8 April 2011 09:29:26 UTC