/irc-logs / w3c / #webapps / 2009-12-10 / end

Options:

  1. # Session Start: Thu Dec 10 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [00:07] * Quits: aroben (aroben@17.203.12.32) (Ping timeout)
  4. # [00:11] * Quits: weinig (weinig@17.246.18.209) (Quit: weinig)
  5. # [00:33] * Joins: weinig (weinig@17.246.18.209)
  6. # [00:40] * Joins: aroben (aroben@17.203.12.32)
  7. # [01:35] * Quits: aroben (aroben@17.203.12.32) (Ping timeout)
  8. # [01:45] * Joins: aroben (aroben@17.203.12.32)
  9. # [02:09] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  10. # [02:25] * Quits: weinig (weinig@17.246.18.209) (Quit: weinig)
  11. # [02:26] * Joins: weinig (weinig@17.246.18.209)
  12. # [02:46] * Quits: ArtB (chatzilla@192.100.104.17) (Client exited)
  13. # [02:47] * Joins: aroben_ (aroben@17.203.12.32)
  14. # [02:48] * Quits: aroben (aroben@17.203.12.32) (Ping timeout)
  15. # [03:02] * Quits: weinig (weinig@17.246.18.209) (Quit: weinig)
  16. # [04:07] * Quits: aroben_ (aroben@17.203.12.32) (Connection reset by peer)
  17. # [04:42] * Quits: shepazu (schepers@128.30.52.169) (Quit: Core Breach)
  18. # [04:51] * Joins: shepazu (schepers@128.30.52.169)
  19. # [04:59] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  20. # [05:04] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  21. # [06:36] * Joins: Lachy (Lachlan@123.3.153.4)
  22. # [06:51] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Ping timeout)
  23. # [07:02] * Quits: Lachy (Lachlan@123.3.153.4) (Ping timeout)
  24. # [07:05] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  25. # [08:16] * Joins: viper23 (Lukas_Schm@80.153.21.122)
  26. # [08:19] * Joins: weinig (weinig@71.198.185.234)
  27. # [08:27] * Quits: arve (arve@212.251.179.162) (Ping timeout)
  28. # [08:35] * Parts: viper23 (Lukas_Schm@80.153.21.122)
  29. # [09:23] * Joins: viper23 (Terminal_I@80.153.21.122)
  30. # [09:26] * Quits: weinig (weinig@71.198.185.234) (Quit: weinig)
  31. # [10:10] * Joins: annevk (opera@83.85.115.44)
  32. # [10:34] * Joins: arve (arve@213.236.208.22)
  33. # [10:53] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  34. # [11:20] * Joins: Lachy (Lachlan@123.3.181.204)
  35. # [11:20] * Quits: Lachy (Lachlan@123.3.181.204) (Quit: Leaving)
  36. # [11:20] * Joins: Lachy (Lachlan@123.3.181.204)
  37. # [11:36] * Quits: Lachy (Lachlan@123.3.181.204) (Quit: Leaving)
  38. # [12:54] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  39. # [13:05] * Quits: annevk (opera@83.85.115.44) (Ping timeout)
  40. # [13:12] * Joins: ArtB (chatzilla@192.100.124.219)
  41. # [13:32] <arve> where's darobin when you need him
  42. # [13:36] * Joins: anne (annevk@83.85.115.44)
  43. # [13:48] * Joins: tlr (tlr@128.30.52.169)
  44. # [13:48] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  45. # [13:59] * Joins: Dashimon (noone@129.241.137.223)
  46. # [14:00] * Quits: Dashiva (noone@129.241.137.223) (Ping timeout)
  47. # [14:00] * Dashimon is now known as Dashiva
  48. # [14:39] * Joins: Lachy (Lachlan@123.3.74.13)
  49. # [14:41] <Lachy> hey shepazu
  50. # [14:42] <shepazu> hey, Lachy
  51. # [14:42] <shepazu> I'm on a telcon right now
  52. # [14:42] <shepazu> I think we've got chaals handling the transition call, sorry I forgot to notify you
  53. # [14:43] <shepazu> thanks for volunteering
  54. # [14:43] <Lachy> oh, ok. It's still on in 20 min, right?
  55. # [14:53] * Lachy wonders where chaals is
  56. # [14:54] * Joins: darobin (robin@78.229.133.72)
  57. # [14:56] * ArtB notes that analysis is significantly easier than synthesis!
  58. # [14:57] <darobin> especially with complex mechanisms
  59. # [15:02] <Lachy> shepazu, who else is supposed to be on this call? Is it just chaals and ralph? Any idea where they are?
  60. # [15:03] * Joins: fjh (fjh@66.30.252.41)
  61. # [15:03] <shepazu> Lachy: I'm on the phone with Ralph now (on another call), no idea where chaals is
  62. # [15:04] <Lachy> shepazu, ok. well, I hope he doesn't take too long to get here. I waited up for this call, despite being quite tired.
  63. # [15:10] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  64. # [15:10] <shepazu> Lachy: sorry, I meant that chaals would be handling it... we don't need you now, and I'm not sure now when it will happen...
  65. # [15:11] <shepazu> I should have told you earlier, but it wasn't clear until later...
  66. # [15:12] <Lachy> oh, great. Now you tell me!. That's why I asked "It's still on in 20 min, right?" earlier!
  67. # [15:12] * Lachy goes to bed
  68. # [15:12] <shepazu> I apologize for the mixed messaging
  69. # [15:12] * Quits: Lachy (Lachlan@123.3.74.13) (Quit: Leaving)
  70. # [15:23] <anne> chaals is travelling
  71. # [15:23] <anne> afaict from his twitter stream he's on a plane
  72. # [15:30] <darobin> either on a plane, or getting to one in London
  73. # [15:30] <darobin> and on drugs, possiblt
  74. # [15:36] * timeless_mbp is now known as timeless
  75. # [15:43] * Quits: arve (arve@213.236.208.22) (Quit: Ex-Chat)
  76. # [15:45] * Joins: arve (arve@213.236.208.22)
  77. # [15:45] <arve> darobin: did you see my comments on File?
  78. # [15:48] <darobin> yes, but I've been at the child doctor almost until the call, haven't had time
  79. # [15:48] <darobin> I'll get to them
  80. # [15:49] <darobin> I've been thinking that we need a fourth spec
  81. # [15:49] <darobin> on that defines streams
  82. # [15:49] <darobin> and we could plug it in a variety of places, possibly including XHR or Web Sockets
  83. # [15:49] <arve> we do
  84. # [15:50] <arve> my main beef with the directory spec, though, is that it doesn't separate cleanly from reader/writer
  85. # [15:50] <darobin> and of course File and friends
  86. # [15:50] <darobin> well it was meant as an integration point :)
  87. # [15:50] <arve> if I gave you some strawman IDL (I don't have time for the rigid definitions today), would you see how they could incorporate
  88. # [15:50] <darobin> but I can probably separate it more, I didn't think orthogonality through
  89. # [15:50] <arve> oh, and I'd like a separate ArchiveCreator spec
  90. # [15:51] <darobin> yes, adding zip() was basically just to remember that
  91. # [15:51] <darobin> I want widgets that can write widgets
  92. # [15:51] <darobin> yes, send me a strawman
  93. # [15:51] <arve> which is fair enough
  94. # [15:51] <darobin> by email preferably
  95. # [15:51] <arve> will do
  96. # [15:51] <darobin> though I probably won't do much today, I'm too knackered
  97. # [15:51] <arve> and now the rest of my week is full :P
  98. # [15:51] <darobin> same here brother
  99. # [15:51] <arve> (I still have capture strawmen to push)
  100. # [15:52] * Quits: arve (arve@213.236.208.22) (Quit: Ex-Chat)
  101. # [15:56] * Joins: steve (elvum@89.16.178.22)
  102. # [16:03] * Joins: marcin (marcin_@82.207.140.22)
  103. # [16:06] <marcin> darobin, steve, resume #wam talk?
  104. # [16:06] <darobin> sure go ahead
  105. # [16:06] <darobin> I have to step out a couple minutes, but I'll catch up
  106. # [16:06] <marcin> ok
  107. # [16:07] <marcin> so the topic is about WARP and specifically allowing specification of the private/local/corporate/home networks there
  108. # [16:08] <steve> which is a hard problem ;-)
  109. # [16:08] <marcin> the draft http://dev.w3.org/2006/waf/widgets-access-upnp/ proposes "local" special value and leaves the actual specification of the set of hosts (i.e. network) to the implementation
  110. # [16:08] <marcin> steve, :)
  111. # [16:09] <steve> which is problematic for widget developers, because they have no guarantee that their application will work for a particular UA without testing it
  112. # [16:09] <marcin> on #wam we discussed whether it would be better to have less or more "special values"
  113. # [16:09] <marcin> the aim is interoperability
  114. # [16:10] <steve> do you think that it is interoperable to leave implementation decisions to the UA developer?
  115. # [16:10] <marcin> we may think of "local" depending on some LBS, e.g. "local" means 1) in the pub I am in, 2) at home, 3) in some network defined by mDNS, 4) in some network defined by IPv4 private range etc
  116. # [16:11] <marcin> steve, WARP is about policy, i.e. about some trust model
  117. # [16:12] <marcin> the model based on "local" is similar to binary distinction that is somehow known, namely Internet vs. intranet
  118. # [16:12] <marcin> the term intranet is loosely defined, I think. It depicts some "trusted" network.
  119. # [16:13] <marcin> I mean a network from which we assume not to be attacked.
  120. # [16:13] <steve> or at least, from which attacks are considered significantly less likely
  121. # [16:14] <marcin> yes
  122. # [16:14] <marcin> WARP already has this concept, all the <access> elements combined define a "trusted" network
  123. # [16:15] <marcin> "local" tries to move the trust from widget developer to the user and UA
  124. # [16:17] <steve> I'd argue that the <access> elements define a "network" that is then compared against some policy, be that written down (by the UA implementer or distributor, perhaps) or in the user's head
  125. # [16:17] <steve> in order to evaluate it for trustworthiness
  126. # [16:18] <marcin> I think <access> is silently assumed to be ultimatively trusted
  127. # [16:18] <steve> interesting
  128. # [16:18] <marcin> ..
  129. # [16:19] <marcin> checking BONDI text for the details
  130. # [16:19] <steve> coming from a mobile perspective, I assumed it would be like JAD permission attributes in J2ME
  131. # [16:20] <marcin> you mean subject to further evaluation?
  132. # [16:20] <steve> yes
  133. # [16:20] <steve> at least in some UA implementations
  134. # [16:21] <steve> particularly in consumer electronics devices, where equipment suppliers want to protect users (or at least, protect themselves from lawsuits/bad publicity)
  135. # [16:24] <marcin> BONDI policy may further restrict the <network-access> policy
  136. # [16:25] <darobin> BONDI's approach is not quite the same as WARP's I believe
  137. # [16:25] <darobin> steve: I don't believe that anyone looked at JAD for this
  138. # [16:25] <darobin> people tend to avoid Java like the plague in these parts
  139. # [16:25] <marcin> steve, if there is some further policy enforcer, then "local" and "*" may be equal anyway.
  140. # [16:26] <marcin> darobin, why? BONDI wants to follow WARP.
  141. # [16:27] <steve> my understanding was that BONDI would adopt WARP instead of its own network-access system when WARP was finalised
  142. # [16:27] <steve> based on a conference presentation at OTA2009
  143. # [16:27] <steve> (where I met marcin, irrelevantly)
  144. # [16:28] <marcin> steve, yes. Current BONDI is a copy of the earlier WARP WD.
  145. # [16:28] <marcin> I think BONDI and WARP match up to the syntax details
  146. # [16:31] <darobin> marcin: yes, BONDI plans to adopt WARP, I was just saying that BONDI's interim solution is different
  147. # [16:31] <darobin> but not necessarily relevantly different for the purpose of this discussion :)
  148. # [16:32] <marcin> darobin, yes :)
  149. # [16:35] <marcin> coming back to the issue whether less or more "special values" is better for IOP:
  150. # [16:36] <steve> I think that any "special value" needs to have a well-defined meaning
  151. # [16:36] <marcin> "local" is now a kind of catch-all and may be good for IOP, but may result is security issues (dependency on the implementation and environment)
  152. # [16:36] <steve> the number should be dictated by what the use cases require
  153. # [16:37] <marcin> "home", "private", "vpn", "mDNS", "upnp" may be more secure, but also be less interoperable
  154. # [16:38] <steve> I'm not sure I'd support that specific set
  155. # [16:38] <marcin> steve, I agree. We would need to define what happens if the value is not understood by the UA (e.g. could be discarded)
  156. # [16:38] <steve> but I suspect this is an optimisation problem
  157. # [16:38] <steve> and that a larger set facilitates a wider range of *potential* use cases
  158. # [16:39] <steve> but not necessarily real use cases, or important use cases
  159. # [16:40] <steve> I also think that it's too soon to decide what the right number is :-)
  160. # [16:40] <steve> given that we currently lack consensus within the WG as to whether the problem even exists at all ;-)
  161. # [16:40] <marcin> :)
  162. # [16:41] <steve> so at some point today or tomorrow I will put up a strawman as agreed, and arve can poke some specific holes in it :-)
  163. # [16:41] <marcin> the initial decision is whether we start with one value and say that we may add some in future (we will not cover all at once), or whether we define one value that should satisfy the future use cases (may be inefficient and simply bad)
  164. # [16:41] <marcin> ok
  165. # [16:42] <steve> marcin: I know you already sent me some links to previous discussions, but if there are others (in particular ones before september) that you can point me at without inconveniencing yourself, that would be very useful
  166. # [16:43] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  167. # [16:43] <marcin> steve, ok. So i do not have to resend the after-september ones?
  168. # [16:43] <marcin> would be an optimization for me
  169. # [16:43] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Ping timeout)
  170. # [16:44] <steve> sure
  171. # [16:44] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  172. # [16:47] * Quits: anne (annevk@83.85.115.44) (Ping timeout)
  173. # [16:55] * Parts: viper23 (Terminal_I@80.153.21.122)
  174. # [17:04] <darobin> steve: re putting forward a strawman, I would suggest that unless you find a silver bullet you limit it it to what you would need to address your use case and not try to solve all the other related or somewhat similar problems
  175. # [17:04] <darobin> that way we can focus on the real needs that you have, and if other use cases crop up or some low-hanging fruits become apparent, we can cross those bridges then
  176. # [17:05] <darobin> it ought to make things simpler, and more rooted in usage, which'll help you against arve :)
  177. # [17:07] <steve> thanks for the advice
  178. # [17:07] <steve> which I will attempt to follow :-)
  179. # [17:07] <darobin> good luck, and it's cool that you could join us
  180. # [17:08] <darobin> be careful not to ever mention interfacing with device functionality — it'll give me the hook I need to drag you into the DAP WG and then you'll be doomed :)
  181. # [17:08] <steve> heh
  182. # [18:07] * Quits: marcin (marcin_@82.207.140.22) (Ping timeout)
  183. # [18:15] * Joins: fearphage (fearphage@69.60.122.35)
  184. # [18:28] * Quits: fearphage (fearphage@69.60.122.35) (Quit: Lost terminal)
  185. # [18:29] * Joins: fearphage (fearphage@69.60.122.35)
  186. # [18:30] * Quits: fearphage (fearphage@69.60.122.35) (Quit: Lost terminal)
  187. # [18:31] * Joins: fearphage (fearphage@69.60.122.35)
  188. # [18:37] * Joins: aroben (aroben@17.246.16.107)
  189. # [18:38] * Joins: aroben_ (aroben@17.203.12.32)
  190. # [18:40] * Quits: aroben (aroben@17.246.16.107) (Ping timeout)
  191. # [19:01] * Quits: darobin (robin@78.229.133.72) (Ping timeout)
  192. # [19:16] * Quits: Marcos (Marcos@213.236.208.22) (Quit: Marcos)
  193. # [19:16] * Joins: Marcos (Marcos@213.236.208.22)
  194. # [19:17] * Quits: Marcos (Marcos@213.236.208.22) (Quit: Marcos)
  195. # [19:45] * Joins: tlr (tlr@128.30.52.169)
  196. # [20:39] * Joins: Lachy (Lachlan@123.3.180.171)
  197. # [20:59] * Quits: Lachy (Lachlan@123.3.180.171) (Ping timeout)
  198. # [21:00] * Joins: Marcos (Marcos@84.215.160.79)
  199. # [21:08] * Joins: smaug (chatzilla@63.245.220.224)
  200. # [21:11] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  201. # [21:49] * Quits: aroben_ (aroben@17.203.12.32) (Ping timeout)
  202. # [22:25] * Quits: timeless (timeless@88.115.8.36) (Quit: timeless)
  203. # [22:30] * Quits: ArtB (chatzilla@192.100.124.219) (Client exited)
  204. # [22:47] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Ping timeout)
  205. # [22:48] * Joins: aroben_ (aroben@17.203.12.32)
  206. # [22:56] <smaug> shepazu: so tX tY for DOM mouse event?
  207. # [22:56] <smaug> (just reading SVG minutes)
  208. # [23:16] <shepazu> smaug: yes, going to collaborate with other (smarter) SVG WG folks to spec it out over the holidays
  209. # [23:18] <smaug> I've discussed about that with jwatt
  210. # [23:18] <smaug> but I guess I need to ask him to explain that again
  211. # [23:18] <smaug> I do understand the reason
  212. # [23:18] <shepazu> yeah, if he has time I'd like to hear his feedback
  213. # [23:19] <smaug> but would just like to see some pseudo-code algorithm for it or something like that
  214. # [23:19] * Joins: weinig (weinig@17.203.14.190)
  215. # [23:19] <shepazu> that's what I'm planning
  216. # [23:19] <shepazu> brb
  217. # [23:39] * Quits: Marcos (Marcos@84.215.160.79) (Quit: Marcos)
  218. # [23:41] * Joins: tlr (tlr@128.30.52.169)
  219. # [23:41] * Joins: timeless_mbp (timeless@88.115.8.36)
  220. # [23:49] * Quits: aroben_ (aroben@17.203.12.32) (Connection reset by peer)
  221. # [23:50] * Joins: aroben (aroben@17.203.12.32)
  222. # Session Close: Fri Dec 11 00:00:00 2009

The end :)