RE: Updated draft charter

See below.

Claes

> -----Original Message-----
> From: Dominique Hazael-Massieux [mailto:dom@w3.org]
> Sent: den 8 april 2011 15:01
> To: Rich Tibbett
> Cc: Nilsson, Claes1; public-device-apis@w3.org
> Subject: Re: Updated draft charter
> 
> 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."

> 
> 
> > 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?
> 
> Dom
> 
> > [1]
> > http://www.whatwg.org/specs/web-apps/current-

> work/multipage/timers.html#custom-handlers
>

Received on Friday, 8 April 2011 13:54:49 UTC