- From: Greg Billock <gbillock@google.com>
- Date: Thu, 19 Apr 2012 12:05:47 -0700
- To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- Cc: public-web-intents@w3.org
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