Re: Updated draft charter

Hi Mike,

Mike Hanson wrote:
> Hello DAP - comment from a Mozilla Labs lurker!
>
> We've been experimenting with this functionality in the Open Web Apps project as well.  I have contributed to the Introducer proposal, though our current prototype doesn't entirely fit the introducer API (but it may converge back to it as we get things working).
>
> I don't have anything useful written up yet but I should have something soon, and will forward a link when I can.  The goal of the experiment is exactly the one sentence you describe in the charter.
>
> For the curious, the "services" branch of github.com/mozilla/openwebapps contains our work; the gallery of concepts at https://apps.mozillalabs.com/gallery/ contains some mockups of our UI designer's latest thinking.
>

I think it's fair to say we've been following progress on Web Introducer 
intently (no pun inten-t-ed).

Under the new charter we'd (Opera) like to explore bringing local 
networked device discovery and interaction to such a model as well - to 
create a single service provider registration point in the UA for Web 
Introducer like interactions. The Web Introducer model lends itself to 
reusing the same services interaction api part for both remote services 
and local networked device services such as TVs, Set-top boxes or other 
in-home devices. In terms of service registration, we would need to 
explore whether alternative registration processes would work for 
networked devices. However any different devices and services are 
registered, the interactions between completely heterogenous devices and 
services could become analogous via a common low-level service 
interaction api.

It's an exciting area and Web Introducer has led to some interesting 
developments. We'll continue to track progress here and hope to take the 
concepts of Web Introducer forward in to new areas, such as those 
discussed above, under the new DAP charter.

Cheers,
Rich

> Best,
> Mike
>
>
> On Apr 7, 2011, at 9:01 AM, 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
>> * 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 Monday, 11 April 2011 07:51:30 UTC