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> 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 6thparagraph 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?


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


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


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

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.


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

Thanks!
-Greg

****
>
> ** **
>
> Best regards****
>
>   Claes****
>
> ** **
>
> [image: cid:3333625383_1036728]
>
> *Claes Nilsson M.Sc.E.E*
> Master Engineer, Research
> Technology Research - Advanced Application Lab
> *
> Sony Mobile Communications*
>  Phone:  +46 10 80 15178
> Mobile: +46 705 56 68 78
> Switchboard: +46 10 80 00000
> E-Mail:* **mailto:claes1.nilsson@sonymobile.com*<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 Tuesday, 13 March 2012 18:27:32 UTC