Re: Proposal for incorporating explicit intent invocation into the object literal constructor

On Thu, Apr 5, 2012 at 3:10 PM, Greg Billock <gbillock@google.com> wrote:

> The use case here is enabling direct access to an intent service's
> intent API from the client page.
>
> 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;
> }
>
> This adds the "service" attribute to the IntentParameters dictionary
> proposed for the object literal syntax. The value stored in this
> attribute must be an absolute URL of a page implementing a qualifying
> web intents service.
>
> If the user agent needs information about the service (i.e.
> disposition, title, etc) for use in preparing its UI, it MAY load the
> service URL and examine the page for the <intent> tag, reading off
> such information. The user agent MUST NOT deliver the intent payload
> to the page unless the Intent filter in the <intent> tag registration
> in the explicit service page matches the intent invocation data
> according to the ation/type matching algorithm, just like for any
> intent delivery.
>
> The expected User Agent behavior is that if this "service" attribute
> is present, the picker SHOULD NOT be displayed (although the User
> Agent is not prohibited from providing the user a way to reroute such
> calls, even though they are marked explicit). Instead, the service url
> SHOULD be loaded directly to handle the intent.
>
> The User Agent MAY ask the user if they wish to install this service,
> just like for any other visit of the page, but SHOULD NOT do so
> automatically.
>
>
Mostly looks good to me.  For those that attended the F2F, explicit intents
was one of the deliverables.


> --------------
>
> Note that this text references a still-to-be-fully-specified matching
> algorithm. We've been working on that, and it'll be along shortly.
> (The outline will be what we talked about in the F2F, we're just
> trying to debug particulars.)
>
> Another question: I'd pondered putting "MUST NOT" instead of "SHOULD
> NOT" in the last sentence about automatic installation. I'm worried
> that this might be a super-cookie, so I think it is probably a bad
> idea, but on the other hand, I don't want to restrict user agents too
> much, as automatic installation may be a really good UI strategy.
>
>
I'm not so much a fan of this wording, since it introduces two different
ways for a service to be registered (automatic, gated).  I prefer having
all registrations automatic (as we agreed upon in the F2F) and moving the
burden of providing the 'best' services to the user to the UA, including a
way to easily remove a service registration.

James