- From: Greg Billock <gbillock@google.com>
- Date: Tue, 24 Apr 2012 13:42:29 -0700
- To: WebIntents <public-web-intents@w3.org>
Another chapter in the proposals coming out of the F2F... This one is about adding a way for the client to propose default services for a particular intent invocation, to make sure the picker will not be empty: -------------- Add an attribute to the IntentParameters dictionary as follows: dictionary IntentParameters { DOMString action; DOMString type; any data; sequence<Transferable> transfer; dictionary<string> extras; URL service; sequence<URL> defaults; } This adds the "defaults" attribute to the IntentParameters dictionary proposed for the object literal syntax. The value stored in this attribute must be a vector of absolute URLs of Services implementing qualifying web intents services. If the user agent needs information about the all or any of the services (i.e. disposition, title, icon, etc) for use in preparing its UI, it MAY load the suggested default service URL(s) and examine the page(s) for the <intent> tag, reading off such information, or load the favicon for the site(s). The User Agent SHOULD ignore the defaults suggested by the intent invocation if the user already has a handler selected. The User Agent MAY ask the user if they wish to install all or any of the suggested default services, just like for any other visit of those page. If the user has no persistent information about a qualifying service registered with the User Agent, the User Agent SHOULD present the user with the option to select from the default handlers proposed by the client at invocation. The User Agent MUST NOT deliver the intent payload to the page loaded as a default unless the Intent filter in the <intent> tag registration in the service page matches the intent invocation data according to the action/type matching algorithm, just like for any intent delivery. If the 'service' parameter is present, invoking an explicit intent, the "defaults" parameter is ignored. ----------------- Some questions. First off, I don't like "defaults". I think it makes it sound like a more permanent default setting, which we want to reserve for something arranged by the user and the UA. I prefer "recommendations". Does that sound good? "recommendedServices"? Any better ideas? I've left it very much up to the UA how to interpret these suggested services. It may want to give the user opportunity to install them, not display them in the case of a default or a preselected alternative, etc. I want developers to be able to expect that providing them means the user won't confront a dead end on an intent invocation. Does this wording adequately communicate that?
Received on Tuesday, 24 April 2012 20:42:58 UTC