- From: Greg Billock <gbillock@google.com>
- Date: Wed, 14 Mar 2012 12:35:24 -0700
- To: "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>
- Cc: "public-web-intents@w3.org" <public-web-intents@w3.org>
- Message-ID: <CAAxVY9e=1K_M8SqYwZmzW=Kmv-xyMzcbx9PVH=-DSuu5TdySdA@mail.gmail.com>
I've updated the document to reflect a lot of this and also to add the "extraData" and "transferList" arguments we've discussed on list. Thanks for the input! I am excited to see the doc getting better. On Tue, Mar 13, 2012 at 11:26 AM, Greg Billock <gbillock@google.com> wrote: > > > 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 Wednesday, 14 March 2012 19:35:53 UTC