/irc-logs / w3c / #webapps / 2009-05-27 / end

Options:

  1. # Session Start: Wed May 27 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [00:00] * Joins: Marcos (Marcos@84.215.160.79)
  4. # [00:02] * Quits: aroben (aroben@17.203.12.32) (Ping timeout)
  5. # [00:07] * Joins: aroben (aroben@17.244.10.207)
  6. # [00:08] * Joins: aroben_ (aroben@17.151.119.212)
  7. # [00:10] * Quits: aroben (aroben@17.244.10.207) (Ping timeout)
  8. # [00:56] * Quits: Marcos (Marcos@84.215.160.79) (Quit: Marcos)
  9. # [01:08] * Joins: annevk (opera@94.210.210.44)
  10. # [01:10] * Quits: aroben_ (aroben@17.151.119.212) (Ping timeout)
  11. # [01:11] * Joins: aroben (aroben@17.246.18.233)
  12. # [01:15] * Quits: heycam (cam@124.168.66.131) (Quit: bye)
  13. # [01:47] * Quits: annevk (opera@94.210.210.44) (Quit: annevk)
  14. # [01:54] * Joins: heycam (cam@130.194.72.84)
  15. # [02:05] * Quits: aroben (aroben@17.246.18.233) (Connection reset by peer)
  16. # [03:51] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  17. # [05:04] * Joins: karl (karlcow@128.30.54.58)
  18. # [07:15] * Joins: phenny (phenny@80.68.92.65)
  19. # [07:33] * Quits: heycam (cam@130.194.72.84) (Ping timeout)
  20. # [07:51] * Joins: heycam (cam@130.194.220.215)
  21. # [08:24] * Joins: annevk (opera@94.210.210.44)
  22. # [09:30] * Quits: heycam (cam@130.194.220.215) (Quit: bye)
  23. # [09:32] * Joins: arve (arve@213.236.208.22)
  24. # [09:38] * Joins: shepazu (schepers@128.30.52.30)
  25. # [09:53] * Joins: heycam (cam@124.168.66.131)
  26. # [09:53] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  27. # [09:54] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  28. # [10:15] * Joins: tlr (tlr@128.30.52.30)
  29. # [10:33] * Joins: Marcos (Marcos@213.236.208.247)
  30. # [10:54] * Quits: Marcos (Marcos@213.236.208.247) (Quit: Marcos)
  31. # [10:56] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  32. # [11:15] * Joins: Marcos (Marcos@213.236.208.22)
  33. # [11:29] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  34. # [12:42] * Joins: ArtB (d0309a43@128.30.52.43)
  35. # [12:43] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  36. # [12:49] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  37. # [13:16] <arve> oh, the widget uri scheme discussion got a whole lot harder
  38. # [13:17] <arve> there is one case where we can't avoid exposing it externally
  39. # [13:17] <arve> cross-document messaging
  40. # [13:18] <tlr> postMessage?
  41. # [13:18] <arve> yes
  42. # [13:18] <tlr> postMessage only needs an origin, not a URI
  43. # [13:19] <arve> the origin attr is a URI, iirc
  44. # [13:19] <tlr> no
  45. # [13:19] <tlr> origin can be a URI *or* a non-URI string.
  46. # [13:19] <tlr> it's the latter for things like sandboxed iframes.
  47. # [13:19] <tlr> or script from data: URIs
  48. # [13:20] <arve> The origin attribute represents, in server-sent events and cross-document messaging, the origin of the document that sent the message (typically the scheme, hostname, and port of the document, but not its path or fragment identifier).
  49. # [13:20] <tlr> of course, the other question is how one widget gets hold of another widget's window object in the first place
  50. # [13:20] <tlr> *typically*
  51. # [13:20] <arve> tlr: not between widgets
  52. # [13:20] <arve> between web pages and widgets
  53. # [13:20] <arve> <iframe> inside a widget
  54. # [13:20] <tlr> right
  55. # [13:21] <tlr> in which case things should work out perfectly nicely
  56. # [13:21] <anne> .origin would just be the empty string
  57. # [13:21] <tlr> ???
  58. # [13:21] <tlr> no
  59. # [13:21] <anne> for widgets, sure
  60. # [13:21] <tlr> no
  61. # [13:21] <tlr> for widgets, it would be a random string
  62. # [13:21] <tlr> that's the point
  63. # [13:21] <anne> unique id becomes empty string per spec
  64. # [13:21] <tlr> whoops, where's that?
  65. # [13:21] <arve> would you ever want to know that the origin was a widget?
  66. # [13:22] <arve> and not some other, undiscoverable origin
  67. # [13:22] <tlr> step back, more explicit
  68. # [13:22] <anne> oh sorry
  69. # [13:22] <anne> it's no longer the empty string
  70. # [13:22] <anne> it's "null" now
  71. # [13:23] <tlr> anne, ref?
  72. # [13:23] <anne> http://www.whatwg.org/specs/web-apps/current-work/#ascii-serialization-of-an-origin
  73. # [13:23] <tlr> thx
  74. # [13:23] * tlr woah, safari 4 beta doesn't behave that nicely on really large documents
  75. # [13:24] <arve> anne mind pointing to the multipage version?
  76. # [13:24] <anne> could be that http://www.whatwg.org/specs/web-apps/current-work/#unicode-serialization-of-an-origin applies here but the result is the same
  77. # [13:24] <anne> section 6.4
  78. # [13:25] <tlr> http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#origin
  79. # [13:26] <tlr> http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages
  80. # [13:26] <tlr> anne, the serialization isn't relevant for postMessage
  81. # [13:26] <tlr> as postMessage refers to the same origin definition
  82. # [13:26] <tlr> http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#same-origin
  83. # [13:27] <tlr> If A and B are both opaque identifiers, and their value is equal, then return true.
  84. # [13:27] <tlr> therefore, as long as the iframe follows the pattern of just calling postMessage back with the .origin attribute it was handed in the first place, all should be fine
  85. # [13:28] <arve> does 'null' qualify as an opaque identifier in this case?
  86. # [13:28] <tlr> null is what you get when you serialize
  87. # [13:28] <tlr> it isn't the opaque identifier itself
  88. # [13:28] <tlr> so the one thing that possibly needs clarification is whether, when ".origin" is passed into postMessage, an opaque identifier survives
  89. # [13:28] <tlr> That's a genuine HTML5 spec question, and needs solving there.
  90. # [13:29] <arve> tlr: the origin then is a guid
  91. # [13:30] <tlr> arve, yes
  92. # [13:30] <tlr> my point is that it doesn't need to be tied to the widget URI scheme
  93. # [13:30] <tlr> (one of the reasons why I don't like that tying is that this would be a URI scheme for which you can never write down an absolute URI -- violates principle of least surprise)
  94. # [13:31] <arve> except if you want to have interaction between web and widget, and authoratively at least know that something is a widget
  95. # [13:31] <tlr> in that case, you'd probably want to know a bit more about the widget
  96. # [13:31] <tlr> like, from whom it came
  97. # [13:32] <tlr> Adam Barth tells me that Mozilla is playing with chrome extensions and doing interesting things with putting public key fingerprints into origins.
  98. # [13:32] <tlr> I think he'll send a note to public-webapps about that soon.
  99. # [13:32] <arve> tlr: chrome extensions as in "Compatible with Google chrome"?
  100. # [13:33] <tlr> as in Mozilla chrome extensions
  101. # [13:33] <arve> or as in "unspecified extensions for the browser chrome, a la jetpack"
  102. # [13:33] <tlr> don't know about compatible with Google chrome, and had parsed this as unrelated to it
  103. # [13:33] <anne> tlr, are you saying no to me again?
  104. # [13:33] <tlr> I understood this to be the latter
  105. # [13:33] <tlr> anne, on what this time?
  106. # [13:33] <tlr> ;-)
  107. # [13:33] * anne is getting a bit annoyed
  108. # [13:33] * tlr chuckles
  109. # [13:34] <arve> what I really don't get with this origin bit is
  110. # [13:34] <anne> you did read the postMessage definition right?
  111. # [13:34] <tlr> yes
  112. # [13:34] <anne> and how it creates an event and sets the origin attribute?
  113. # [13:34] <arve> the origin attribute is specified as a DOMString, then it _will_ be null for comparison purposes
  114. # [13:34] <arve> (which is anne's point)
  115. # [13:35] <anne> specifically: "the origin attribute must be set to the Unicode serialization of the origin of the script that invoked the method"
  116. # [13:35] <tlr> argh
  117. # [13:35] <tlr> overlooked that piece, and suspect that it's a bug in html5
  118. # [13:36] <anne> you know, maybe I'll say no now
  119. # [13:36] <tlr> ;-)
  120. # [13:36] <tlr> look, the reason for targetOrigin is to make sure that the target window of a postMessage hasn't been navigated elsewhere
  121. # [13:37] <anne> yup
  122. # [13:37] <tlr> for the origin attribute on the MessageEvent, you've got two purposes:
  123. # [13:37] <tlr> 1. feed into targetOrigin when responding. In this case, it's fine to just pass through an opaque origin
  124. # [13:38] <tlr> 2. compare to some string that you know of. In this case, you'll actually want to do the serialization
  125. # [13:38] <tlr> so, what I'm saying is that origin is cast to DOMString too early in the spec
  126. # [13:38] <tlr> since you break the ability to pass messages back to anything that had a synthetic origin
  127. # [13:38] <anne> actually, you want do that the other way around
  128. # [13:38] <tlr> why?
  129. # [13:39] <anne> you're not going to reply before knowing if you trust them
  130. # [13:39] <tlr> depends on the use case
  131. # [13:39] <tlr> you might very well be exposing a public API
  132. # [13:39] <anne> in that case you'd use "*"
  133. # [13:39] <tlr> not necessarily
  134. # [13:39] <anne> why not?
  135. # [13:40] <tlr> I might very well want to send a response to the precise guy from whom the question came, to not leak their private information to a third party
  136. # [13:40] <tlr> without caring who they are
  137. # [13:40] <tlr> being able to pass through origin even when it's an opaque identifier gives me that ability
  138. # [13:40] <anne> interesting point
  139. # [13:40] <tlr> casting to DOMstring earlier breaks it
  140. # [13:40] <tlr> therefore, spec bug
  141. # [13:40] * Quits: heycam (cam@124.168.66.131) (Ping timeout)
  142. # [13:40] <anne> not necessarily
  143. # [13:41] <anne> only if opaque id origins are considered relevant enough
  144. # [13:41] <tlr> (and yes, you're totally right about the "compare to some known URI" use case for having a string representation -- not disputing that)
  145. # [13:42] <anne> so basically you want .origin to become some kind of Origin object that stringifies to "null" or an actual origin
  146. # [13:43] <tlr> yes
  147. # [13:43] <anne> for quite a minor use case
  148. # [13:43] <anne> feel free to go for it :)
  149. # [13:43] <tlr> lol
  150. # [13:46] * Joins: heycam (cam@210.84.19.113)
  151. # [13:59] <tlr> http://lists.w3.org/Archives/Public/public-html/2009May/0478.html
  152. # [14:43] * Joins: taf2 (taf2@38.99.201.242)
  153. # [16:00] <ArtB> shepazu, how about capturing http://www.w3.org/mid/4A1C76D9.9040607@w3.org in the Widgets V2 UC + Reqs doc -> http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R
  154. # [16:23] * ArtB is now known as ArtB_
  155. # [17:17] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
  156. # [17:39] * Quits: arve (arve@213.236.208.22) (Client exited)
  157. # [17:42] * ArtB_ is now known as ArtB
  158. # [18:06] * Quits: annevk (opera@94.210.210.44) (Quit: annevk)
  159. # [18:08] <Marcos> Artb, so what was the next priority?
  160. # [18:09] * Marcos prints A&E and DigSig, and arms himself with a red pen!
  161. # [18:17] <ArtB> Marcos, A+E!
  162. # [18:17] <ArtB> let's get that puppy to LC as soon as we can
  163. # [18:17] * Marcos is on it!
  164. # [18:18] <ArtB> And don't worry about that A+E Editor named Arve -> just do the right thing :-)
  165. # [18:18] <Marcos> :)
  166. # [18:29] * Quits: Marcos (Marcos@213.236.208.22) (Quit: Marcos)
  167. # [18:51] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  168. # [19:02] * Joins: darobin (darobin@82.233.247.234)
  169. # [19:05] * Joins: aroben (aroben@17.246.18.201)
  170. # [19:29] * Joins: msJacobRossi (836b0053@128.30.52.43)
  171. # [19:31] * Quits: msJacobRossi (836b0053@128.30.52.43) (Quit: CGI:IRC)
  172. # [19:32] * Joins: jrossi (836b0053@128.30.52.43)
  173. # [19:40] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC (EOF))
  174. # [19:46] * Quits: darobin (darobin@82.233.247.234) (Quit: darobin)
  175. # [20:03] * Joins: annevk (opera@94.210.210.44)
  176. # [20:35] * Joins: shepazu (schepers@128.30.52.30)
  177. # [20:36] * Quits: aroben (aroben@17.246.18.201) (Quit: aroben)
  178. # [20:47] <jrossi> shepazu, are we meeting?
  179. # [20:48] <shepazu> jrossi: no, sorry, I'm at Google I/O
  180. # [20:48] <shepazu> next week, both chaals and I will be available
  181. # [20:48] <shepazu> and I'll update the document :(
  182. # [20:48] <jrossi> A couple of our other folks are there as well.
  183. # [20:48] <jrossi> Thanks!
  184. # [20:48] <shepazu> np
  185. # [20:48] <jrossi> (Travis says hi.)
  186. # [20:49] <shepazu> howdy, travis :)
  187. # [20:50] <jrossi> Good luck at Google I/O. We're going offline...
  188. # [20:54] * Quits: jrossi (836b0053@128.30.52.43) (Quit: CGI:IRC)
  189. # [20:57] * Quits: annevk (opera@94.210.210.44) (Quit: annevk)
  190. # [21:11] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
  191. # [21:14] * Joins: ArtB (d0309a43@128.30.52.43)
  192. # [21:21] * tlr is now known as tlr-off
  193. # [22:29] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC (EOF))
  194. # [22:32] * Joins: aroben (aroben@17.246.18.201)
  195. # [22:40] * Joins: arve (arve@84.202.133.45)
  196. # [23:31] * Joins: Marcos (Marcos@213.236.208.22)
  197. # Session Close: Thu May 28 00:00:00 2009

The end :)