Re: questions on the April 11th draft

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 ?

/"This explicit unregistration///should/be supported for same-origin 
pages as well./"

What does that mean ? same-origin pages ?

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