RE: questions on the April 11th draft

On "a way to refresh the registration", the approach you mention for installable Webapps makes sense (browser will handle that automatically). For general Web pages, I did not mean that the browser would automatically check the status of a page upon an expires value being exceeded, only that the browser could alert the user somehow (mark the Intent in a picker UI?) and allow the user to manually check if the Intent is still valid. But now that you mention it, I can also see value in a setting that authorizes the browser to automatically revalidate registered intents on a periodic basis, and remove dead ones. I personally would like that feature, as I really don't want to do any more work than I have to as a user, because of Intents.

I will watch for the related text on "no longer accessible" intents pages, and comment.

On the MUST vs SHOULD, I do think that "allow the user ..." provides the desired flexibility for the implementation to determine when/how the user is allowed to make a decision. I just would not want the SHOULD to imply that user choice on whether intents are registered is optional.

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Greg Billock [mailto:gbillock@google.com] 
Sent: Wednesday, April 25, 2012 5:11 PM
To: SULLIVAN, BRYAN L
Cc: Jean-Claude Dufourd; public-web-intents@w3.org
Subject: Re: questions on the April 11th draft

On Sun, Apr 22, 2012 at 5:42 PM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
> 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.

That's a similar suggestion to one Hiroyuki Aizu made at the F2F
meeting -- an "expires" attribute of the intent tag.

I'd like to avoid requiring the user agent to refresh any non-loaded
page on any interval -- I'm worried there are privacy implications
there. For installed app support in Chrome, the browser will take care
of this kind of refreshing behavior. Do you have a sense on how to
make this work well for web content at large?

> 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.

This make sense. Currently the spec leaves this up to the UA pretty
completely. I'll put this in my notes to add to a recommendations
section.


> 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.

My hesitation there is more around wanting to provide good leeway to
the UA to make tradeoffs between permissions notifications and
interruptions. That is, a perfectly valid usability decision might be
"we'll suppress notification on the first and second visits, but on
the third, we'll consider the user sufficiently interested in the site
to show the registration notification." Such policies might have
better ergonomics than a MUST requirement. Or do you think "allow the
user ..." provides the desired flexibility?

> 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 Thursday, 26 April 2012 03:53:19 UTC