RE: Updated draft charter

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
* The possibility for web applications to request access to a handler/provider of a certain data type
* 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."

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 Thursday, 7 April 2011 16:02:16 UTC