Re: possibly additional requirement for web intents

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-intents/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,optionalcallback  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 - Mob: +33677843843 - Fax: +33145817144