Re: Updated draft charter

Nilsson, Claes1 wrote:
> Dominique Hazael-Massieux  wrote:
>>
>> Le vendredi 08 avril 2011 à 11:28 +0200, Rich Tibbett a écrit :
>>>> 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.
>> I agree data type might be confusing, but "intent" seems to be too
>> ill-defined for use in a charter, I would think. Input on a phrasing
>> that is both clear enough and short enough would be most welcome.
>
> I struggled with the wording here and also agree that "data type" is not good.
>
> In Android context an "intent" is a an abstract description of an operation to be performed. An intent contains the action to be performed, typically launching an activity, and the data to operate on. An example is launching the Youtube application through an intent when the browser detects a link to a Youtube video.
>
> In the Web Introducer context a provider handles one or more data types that is defined as "a string identifying an interaction pattern between a Customer and a Provider". Examples are "link to a bookmark", "link to a media file of type mpeg", "sms".
>
> What about?
>
> "An API that allows web applications to register themselves as handlers/providers based on an identified data string and an API that enables other web applications to discover these handlers/providers and gain permission to interact with them."
>

Sounds good but let's replace [an identified data string] with [data 
string identifiers] for reuse as a keyword.

Apart from that it looks good. Are we going to have a go at 
standardizing "data string identifiers" or not? That's something we 
might want to lock down early.

>>
>>> 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.
>> Agreed; but does that need any addition to the charter? Or are we fine
>> with the current list of deliverables?

I imagine that we'd want the output of device capabilities from a 
Discovery API to be compatible with the data string identifiers input to 
an Intents API. Then we can reuse the same interaction mechanisms for 
remote service, local device and networked device communication.

The only addition I could think of would be to use the term 'data string 
identifiers' to go with Claes's rewording above, in the context of the 
Discovery API deliverable item also:

"An API to discover devices and services and their capabilities, as data 
string identifiers, on the same device, on the local network, or 
directly connected, e.g. by USB and Bluetooth."

- Rich

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

Received on Friday, 8 April 2011 15:01:14 UTC