- From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- Date: Mon, 16 Jul 2012 18:18:35 +0200
- To: James Hawkins <jhawkins@google.com>
- CC: public-web-intents@w3.org
- Message-ID: <50043EDB.50503@telecom-paristech.fr>
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 UTC