Re: questions on the April 11th draft

Thanks for the feedback, I'm updating the proposal now with much of
it. Any more? Keep it coming!

On Thu, Apr 19, 2012 at 1:57 AM, Jean-Claude Dufourd
<jean-claude.dufourd@telecom-paristech.fr> wrote:
> Thanks a lot, I think I now get what I misunderstood.
>
> I believed that the page registering the intent needed to stay loaded for
> the intent to be active, that as soon as the page was unloaded, the intent
> was inactive.
> I now think I was wrong, please confirm.
>
> I think there is no explicit text to the contrary, and maybe there should
> be.
> There is only something rather indirect, saying the service page may be
> loaded in different contexts according to the disposition attribute.
> What do you think ?
>
> I have further comments on the draft below.
>
> There are variations in the vocabulary that make it difficult to follow,
> e.g. are "intent caused by" and "intent invoked by" synonyms ?
>
> In sub-section "unregistering", there are sentences which puzzle me:
>
> "That is, a page may unregister itself quietly by removing all intent tags,
> or explicitly by keeping the tag present, but empty."
>
> A page is "passive". Some user or process needs to load the unregister page
> right ? This cannot happen automatically ? Or did I miss something again ?

That's correct. The goal here is for a site to be able to manage its
registered intent handlers without the user needing to visit the
service page specifically.

> "This explicit unregistration should be supported for same-origin pages as
> well."
>
> What does that mean ? same-origin pages ?

Pages with the same origin (domain).

So for instance, on page http://example.com/a.html, I could have

<intent action="foo" type="bar" href="http://example.com/b.html"></intent>

Which registers that service. Since it is on the same origin, this tag
should be honored. This tag:

<intent action="foo" type="bar"
href="http://anotherexample.com/b.html"></intent>

would not -- it is trying to register a cross-origin service.

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.

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

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

>
> Thanks
> JC
>
>
> On 19/4/12 04:05 , Greg Billock wrote:
>
> Thanks for the feedback.
>
> On Tue, Apr 17, 2012 at 9:52 AM, Jean-Claude Dufourd
> <jean-claude.dufourd@telecom-paristech.fr> wrote:
>
> Dear editors,
>
> In section 2.1, the following text seems to have a problem:
> A Service is a web page which can handle an Intent, possibly returning a
> piece of data to the calling Client page. Again, the User Agent may have
> ways to deliver Intents to Services which are not web pages.
> The first sentence says "a service is a web page..."
> The second sentence says "services which are not web pages".
> Seems like a contradiction to me.
> I suspect the first sentence should be "inverted": a web page which can
> handle an intent is a service
> Is that right ?
>
> Yes, that's more correct. The spec doesn't really directly deal with
> non-web-content services, but I like that wording better.
>
>
> In section 3.2 " The Intent object models a particular task which can be
> requested by handled by client pages."
> Would that be " The Intent object models a particular task which can be
> requested to be handled by client pages." ?
>
> Oops! Thanks.
>
> Language in the last example and elsewhere makes me wonder about the
> "loading status" of page A defining an intent B.
> Page A is loaded.
> Then intent B is registered.
> Then page A is unloaded.
> What is the status of intent B ?
> If intent B is still "on", is page A reloaded upon a successful request to
> intent B ?
>
> So if A invokes an intent, which is then delivered to another page, if
> A is unloaded (i.e. the user closes the tab) that need not close the
> service page. Ultimately the policies there about which tabs or
> contexts are coupled is up to the user agent to control, but in
> general, delivering an intent to a new context is really a new context
> -- the invoking page (A) can disappear and the new context can still
> be just fine.
>
> For inline disposition, Chromium code currently doesn't really offer a
> way to close the invoking container without closing the service
> container as well. For window disposition, we do.
>
> That kind of page lifecycle is something that needs work in the User
> Agent Behavior section.
>
> -Greg
>
>
> Thanks
> JC
>
> --
> 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
>
>
>
> --
> 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 Thursday, 19 April 2012 19:06:21 UTC