W3C home > Mailing lists > Public > public-web-intents@w3.org > July 2012

Re: possibly additional requirement for web intents

From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
Date: Mon, 16 Jul 2012 18:18:35 +0200
Message-ID: <50043EDB.50503@telecom-paristech.fr>
To: James Hawkins <jhawkins@google.com>
CC: public-web-intents@w3.org
Generic use case: gather a list of available "stuff" from all local, 
online devices
Rationale: the user could not care less about where is a particular 
"stuff" provided it is available now. So any "stuff"-choosing widget 
should ignore the localization of "stuff", and only present collated lists.

Possible "stuff":
- playable media
- possible tasks
- context information (media currently playing, other current activity)

I really believe broadcast intents are a killer feature for locally 
discovered services.
Best regards
JC

On 16/7/12 15:41 , James Hawkins wrote:
> Jean-Claude, Android Intents (the namesake of Web Intents) has 
> 'broadcast intents', which essentially do what you are asking for: 1:n 
> intent invocation.  We haven't added this to Web Intents yet mostly 
> due to lack of compelling use cases.  If you have a particular use 
> case in mind, please share.
>
> Thanks,
> James
>
> On Mon, Jul 16, 2012 at 2:14 AM, Jean-Claude Dufourd 
> <jean-claude.dufourd@telecom-paristech.fr 
> <mailto:jean-claude.dufourd@telecom-paristech.fr>> wrote:
>
>     Thanks Greg. Comments inline.
>
>
>     On 12/7/12 22:53 , Greg Billock wrote:
>>     At this point, I'm not sure how you'd do this kind of thing with
>>     web intents. The feature isn't really aimed at enumeration, but
>>     rather at invocation/delivery.
>>
>>     Having a method to get all available services, however, is an
>>     interesting solution to the problem of "isHandlerRegistered" that
>>     could do double-duty for things like this. I am pretty worried
>>     about the privacy implications of any enumeration API. Such an
>>     enumeration API is fertile ground for extensions, though -- does
>>     that address this use case?
>     JCD: I share your worry about an enumeration API. I do not see my
>     proposal as having the same problem.
>     One way to implement my proposal is to modify startActivity (or
>     add a variant):
>
>          void  startActivity  <http://dvcs.w3.org/hg/web-i%20ntents/raw-file/tip/spec/Overview.html#widl-Intents-startActivity-void-Intent-intent-callback-onSuccess-callback-onFailure>  (|Intent|  <http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#idl-def-Intent>  intent, DOMString pickingPolicy,optional <
>       span clas
>     s="idlParamType" style="color: rgb(0, 90, 156); ">callback  onSuccess,optionalcallback  onFailure);
>
>     pickingPolicy would be one of:
>     - 'pickOne': default value, the current behavior
>     - 'pickMultiple': creates a picker which allows the selection and
>     triggering of multiple providers
>     - 'triggerAll': do not show a picker, activate all registered
>     intent providers
>
>     The callbacks would have to be appropriate to multiple calls.
>
>     This does not seem to provide hooks for fingerprinting, whereas an
>     enumeration API would.
>     What do you think of this ?
>     Best regards
>     JC
>
>
>>
>>     The image I have in mind is that there's an web application which
>>     wants to essentially perform the task of the picker -- presenting
>>     a list of possible services to the user. That's doable, but is
>>     something we've so far envisioned remaining the province of the
>>     UA (and perhaps extensions), and not being available to web
>>     content unless they want to use explicit intents to manage such a
>>     feature.
>>
>>
>>
>>
>>
>>
>>     On Thu, Jul 12, 2012 at 8:59 AM, Josh Soref <jsoref@rim.com
>>     <mailto:jsoref@rim.com>> wrote:
>>
>>         I think you could have:
>>         A "start" intent which a task manager could use to let the
>>         user pick a task to run. Each task could register for "start"
>>         and when the user clicks a "start something" button, the task
>>         manager triggers the start intent and the UA lets the user
>>         pick a task.
>>
>>         I think task management itself would be better via WebSockets
>>         than WebIntents.
>>
>>         You could have a task manager intent which offers some
>>         WebSocket protocol, and if a UA receives whitelist permission
>>         from the User for your task manager to continue talking to a
>>         device, then it could probably do more or less seamless setup
>>         for future invocations.
>>
>>         UI in general is left to UAs, and the general intent design
>>         is 1-1, not 1-many. You could make n requests to get access
>>         to n "task managers", and a UA as a QoI detail could elect to
>>         bubble the requests into a multiselect dialog.
>>
>>         That certainly won't be the initial UI implementation,
>>         although if the UC is shown to be compelling, UAs may shift
>>         to accomodate that.
>>
>>         In terms of 1-many proposals, richt's proposal is friendlier
>>         to this.
>>
>>         At this time, WebIntents is a big enough task, so I think
>>         addressing this would be future work.
>>         ---------------------------------------------------------------------
>>         This transmission (including any attachments) may contain
>>         confidential information, privileged material (including
>>         material protected by the solicitor-client or other
>>         applicable privileges), or constitute non-public information.
>>         Any use of this information by anyone other than the intended
>>         recipient is prohibited. If you have received this
>>         transmission in error, please immediately reply to the sender
>>         and delete this information from your system. Use,
>>         dissemination, distribution, or reproduction of this
>>         transmission by unintended recipients is not authorized and
>>         may be unlawful.
>>
>>
>
>
>     -- 
>     JC Dufourd
>     Directeur d'Etudes/Professor
>     Groupe Multimedia/Multimedia Group
>     Traitement du Signal et Images/Signal and Image Processing
>     Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
>     Tel:+33145817733  <tel:%2B33145817733>  - Mob:+33677843843  <tel:%2B33677843843>  - Fax:+33145817144  <tel:%2B33145817144>
>
>


-- 
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Received on Monday, 16 July 2012 16:19:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 16 July 2012 16:19:10 GMT