Re: possibly additional requirement for web intents

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> 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, optional callback 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> 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 - Mob: +33677843843 - Fax: +33145817144
>
>