RE: Web Intents W3C Editor's Draft 31 January 2012 - Review comments

Thanks for your reply Greg. In addition to latest submissions on the syntax for the API see inline for my further comments.

Best regards
  Claes

________________________________
From: Greg Billock [gbillock@google.com]
Sent: Tuesday, March 13, 2012 7:26 PM
To: Nilsson, Claes1
Cc: public-web-intents@w3.org
Subject: Re: Web Intents W3C Editor's Draft 31 January 2012 - Review comments



On Tue, Mar 13, 2012 at 12:52 AM, Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com<mailto:Claes1.Nilsson@sonymobile.com>> wrote:
Hi,

As a preparation for the Web Intents session in Shenzhen I am reviewing the draft Web Intents specification, http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html. Some initial comments below:


•         Service Registration generally:

I am a bit puzzled on what the specification normatively says on Service registration.

To me a page that registers a Service is logically separated from a page that implements a Service handler. However, the specification seems to see this as the same. I understand that one page could contain the Service registration markup and another page could act as Service handler through the href attribute in the first page but I interpret the specification to be inconsistent on whether a Service handler page needs to contain the registration markup.



The last paragraph of section 3.3 states that the window.intent object is available to Service handler pages under the condition that they are within the same origin as the Service registration page. However, the 6th paragraph of section 3.4 states that user agents MUST NOT place a window.intent object in the scope of pages which do not have registration metadata declaring themselves as intent handlers.



So does an intent handling Service page have to have registration markup for itself or not?

Yes, it does, but a separate page may also have registration markup for a same-origin service.  That is, you can have

register.html:
<html>
...
<intent ... href="service.html">
...
</html>

and service.html:
<html>
...
<intent ...>
<script> window.intent....
</html>

Is there a better way to communicate that?



The last paragraph of section 2.1 also  states that intent handling Services can be something else than web pages and the 3rd paragraph of section 4 states that the User Agent may provide additional mechanisms for web intents service registration. All this is inconsistent with a normative statement  that a Service handler MUST contain the registration markup.

This should be changed to indicate that a "web-app Service handler MUST ...", as obviously non-web-app handlers would have some other mechanism for indicating to the UA that they will handle web intents. Do you want to raise a bug for this?

Claes: Ok, I'll review the latest version.




•         Section 2.2

It is stated: “Registration is how a Service page informs the User Agent that it is capable of handling Intents.”

The wording should also include a statement that another, referenced page, it is capable of handling Intents



•         Section 3.4

- Service as web worker? We can’t expect all intent handling Services to have a UI. Have you considered allowing workers? If so, an option is to allow the value “worker” for the disposition attribute in the registration markup.

We've discussed this at length, and currently believe that a service needs to have a UI surface. This is something we should discuss, though, as there may be use cases for Worker handlers. (We called that "background" disposition.)

Claes: I can think of a lot of use cases for Web Intents where the Service handler has no UI. One obvious example is a web application that is controlled by a sensor, e.g. an accelerometer, in a remote device. Why should such a Service have a UI surface once it has been selected by the user? However, I  am not sure that a worker is the best solution for for an "invisible" / "background" Service. A hidden iFrame might also be a solution. Most important for now is that these types of Services should be supported by the Web Intents framework.


- Paragraph 3: “The User Agent may provide additional mechanisms for web intents service registration. For example, by external applications, through a separate API, as a result of a permissions bundle in a downloaded web application, or pre-bundled.”
I would like to add the example of dynamic local network Services, e.g. UPnP services. This means that the UA’s Web Intents framework must be able to manage the Service availability as the connection with them will come and go.

Definitely. That'd be a great addition. This draft is pretty vague on any of that, leaving it up to the UA. If there are specific requirements for, say, UPnP service registration that might best fit in another doc, but having an example here would be very nice.

Claes: I have described such a use case at the wiki: http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents#Opt_3 and I am working on a presentation for Shenzhen describing this in more detail.


- The last paragraph states that web sites could unregister Service handlers by including the <intent> element but having both Action and Type attributes empty or omitting them. Seems to be a typo in the sentence “That is, a page may unregister itself quietly by removing the tag altogether, or explicitly by keeping the tag present, but empty.”  Guess it should be “tags”. Furthermore, is it possible to unregister a referenced Service handler page by omitting the Action and Type attributes but keeping the href?

Good point. I'll rework this to make it clearer. The intention is that any (same-origin, of course) registering page can also unregister explicitly by taking out action/type. Quiet unregistering would not work for off-page registration, but would work for the service page itself. (This means the UA is relieved of responsibility to remember where the registration came from, but will respond to explicit signals from that origin, and obviously from failed delivery attempts on the service in question.)

Claes: Ok. New version is clearer.

Another thought here: we should include a description (not sure if all of it would be MUST...) of what the UA should do for various HTTP error codes on the service page.

Claes: I agree that this is needed.


- Paragraph 8: “The User Agent should allow any serializable and/or Transferable object to be passed between client to service and back from service to client. This includes Blobs [BLOB], MessagePorts, etc.”
Don’t we require a MUST here due to interoperability reasons?

The intention here was to not couple web intents support too tightly to things like Blob, ArrayBuffer, MessagePort, or any particular other transferable. That is, the intention is to say "if you've got 'em, they should work" rather than "to implement web intents, you must have all these other features too." The reason for my conservatism there is that some UAs may not have support for these kinds of structures, but could still participate with a large number of web intents use cases. Perhaps the right way to convey that, though, is to add MUST here, and then such UAs would just have partial support, which is a fine way to think about it.

Claes: The discussion on transferring messagePorts is ongoing on the list and I am following this.

Thanks!
-Greg


Best regards
  Claes



Claes Nilsson M.Sc.E.E
Master Engineer, Research
Technology Research - Advanced Application Lab

Sony Mobile Communications
 Phone:  +46 10 80 15178<tel:%2B46%2010%2080%2015178>
Mobile: +46 705 56 68 78<tel:%2B46%20705%2056%2068%2078>
Switchboard: +46 10 80 00000<tel:%2B46%2010%2080%2000000>
E-Mail: mailto:claes1.nilsson@sonymobile.com<mailto:claes1.nilsson@sonyericsson.com>
Visiting Address; Nya Vattentornet
SE-221 88 LUND,
Sweden
Disclaimer:
The information in this e-mail is confidential and may be legally privileged. It is intended solely for the named recipient(s) and access to this e-mail by anyone else is unauthorized. The views are those of the sender and not necessarily the views of Sony Ericsson and Sony Ericsson accepts no responsibility or liability whatsoever or howsoever arising in connection with this e-mail.Any attachment(s) to this message has been checked for viruses, but please rely on your own virus checker and procedures. If you contact us by e-mail, we will store your name and address to facilitate communications. If you are not the intended recipient, please inform the sender by replying this transmission and delete the e-mail and any copies of it without disclosing it.

Received on Thursday, 15 March 2012 01:24:25 UTC