RE: questions on the April 11th draft

To address the removal of intents without the user having to browse back to the site, I recommend that a couple of things be considered:

1) An expiration element that defines how long the intent will remain registered. When it expires, the user could be informed somehow through the UI, and potentially given a way to refresh the registration.

2) Recommendations on what the user agent should do if an intent registration page is no longer accessible, e.g. inform the user that the service may no longer be available, and offer the option to remove it.

These might go a long way to avoiding the cluttering of old intents in the browser UI, as the user surfs around the net and these things collect like barnacles (one of my hesitations with the overall registration design). At least I would be more comfortable with a MUST requirement on "When the User Agent loads a page with registration markup, it should allow the user to configure that page as a web intents service." Rather than a SHOULD.

Thanks,
Bryan Sullivan

-----Original Message-----
From: Greg Billock [mailto:gbillock@google.com] 
Sent: Friday, April 20, 2012 11:18 AM
To: Jean-Claude Dufourd
Cc: public-web-intents@w3.org
Subject: Re: questions on the April 11th draft

On Fri, Apr 20, 2012 at 12:08 AM, Jean-Claude Dufourd
<jean-claude.dufourd@telecom-paristech.fr> wrote:
> Thanks for your answers. More questions inline.
>
>
> On 19avr. 21:05, Greg Billock wrote:
>>
>> To unregister, I can put on  http://example.com/a.html the markup:
>>
>> <intent href="http://example.com/b.html"></intent>
>>
>> which basically says "this service handles no intents." Since it is
>> same-origin, it should be honored.
>
> JCD: If you just change a.html this way, when is the intent unregistered ?

When the user visits a.html.

> Are you doing another action with that change to get a.html to be processed
> by the browser ?

No. A goal is for registration and deregistration to be driven by
things the browser discovers in normal operation. This obviously needs
to be precise, but a sketch of the algorithm I have in mind is this:

When the user visits a page with an <intent> tag on it (which is
same-origin, cross-origin tags are ignored), the UA is provoked to
check its registry and possibly make adjustments:

If the tag registers a new handler, or an unknown filter for a known
handler, the UA can prompt the user for registration confirmation.
If the tag unregisters a known handler (omitting the filter), then it
is unregistered.

(The filter is the action/type attributes.)

In addition, if the UA loads a known intent service page, it'll make
sure the registration records are updated to match the authoritative
declarations on that page.

This algorithm means the UA only does something when it actually is
triggered by parsing a tag (or possibly by handling a call from the
imperative mechanism, which seems likely to happen). Pages that don't
have any intents API on them don't trigger anything.

Note that this is all a bit different from extensions/apps that handle
intents, which can potentially have their registration settings be
updated using other mechanisms.

> Or is a.html sitting there with the intent still registered in the browser
> until the next time someone invokes it,
> so a.html is loaded, the browser sees the unregistering, and has to go back
> up into intent resolution ?
> This assumes that the registration markup page is the same as the service
> page.
> If so, I am not sure I like it.

There is a hole here -- if a service provider stops offering a service
on a page, the browser may still dispatch to that page, since it
doesn't know the support has been removed. I agree that this is not
nice, but neither is any 404. Ideally the page redirects to the new
service page on the provider. There are definitely edge cases here
that result in the user having to go back to the picker and deal with
their chosen service provider having ceased operations, though.

> If the registration markup page and the service page are different, then I
> have no idea when the intent will ever be unregistered.
>
> Note: please add an example with separate registration markup page and
> service page. Thanks.
>
>>
>> Let me note quickly that this is the registration interaction with the
>> browser, which is a little tricky. For instance, if a captive portal
>> returns unrelated HTML to a request for a service page, should the
>> browser be forced to unregister it? Hopefully not.
>
> JCD: Actually, there are two variants of your question:
>
> - if a registration markup page is loaded "again" and this time there is no
> intent registration in there, yes, probably, no change to the intent
> registration DB.
>
> - if a service page is loaded and it does not contain any intent processing
> code, what happens ?
> -- definitely, the intent will get no response (if one was in order)
> -- should there be an error message ? I think yes.
> -- should the intent be removed from the intent registration DB ? I would
> argue it should, yes.
>
> However, I do not know if the browser can throw an error, because its task
> is to just load the service page. If nothing happens, what is there to alert
> the browser that something is wrong...

If there's no matching intent declaration on the page, the intent
won't even be delivered. But in that case, the UA can fall back either
to select another service, or notify the caller via postFailure that
the intent could not be delivered.


>
>>  But the interaction
>> of the tag and intent delivery is of a MUST nature -- the UA won't
>> deliver an intent to a page that doesn't expect it.
>
> JCD: That means intents are going to be HARD to debug. If the service page
> is clobbered, silent failure ? I do not like it...

>From the client's perspective, the failure isn't silent, and can be
handled pretty readily. From the integration perspective, the failure
mode is somewhat like finding 404 links on your site -- if you're
suggesting obsolete services to users, you have to discover that and
suggest new ones. If you're not, it is the UA's problem. So it is an
easier debugging problem than having a third-party app changing their
API on you.

Am I misunderstanding which debugging process you're thinking of?
Clearly there's possible bugs in the caller which could lead to
persistent delivery failures.

>
>
>>
>> At some point, this'll get tuned into an algorithm spec for dealing
>> with the<intent>  tag. I'm holding off on that a bit because it's
>> likely to grow a little more complicated as we consider
>> registerProtocolHandler/registerContentHandler issues with
>> registration. (See the WhatWG list.)
>
> JCD: Are you saying a significant part of the web intents discussion happens
> on the WhatWG list ?
> Or just talk that has impact on Web Intents ?

The <intent> tag is in HTML, and so is discussed there, yes. That's
the mechanism we've proposed for registration issues, so issues
pertaining to that whole (important) question are in active debate
there.

-Greg

Received on Monday, 23 April 2012 00:43:18 UTC