Re: possibly additional requirement for web intents

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

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 
> < 
> <>> 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  <>  (|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 <
>>     <>> 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 UTC