/irc-logs / w3c / #webapps / 2009-04-20 / end

Options:

  1. # Session Start: Mon Apr 20 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [00:17] * Joins: shepazu (schepers@128.30.52.30)
  4. # [00:46] * Joins: Marcos (Marcos@84.215.160.79)
  5. # [01:23] * Quits: Marcos (Marcos@84.215.160.79) (Quit: Marcos)
  6. # [01:26] * Quits: heycam (cam@124.168.17.176) (Quit: bye)
  7. # [03:26] * Joins: heycam (cam@130.194.73.110)
  8. # [04:19] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  9. # [06:48] * Quits: timeless (timeless@65.75.195.122) (Ping timeout)
  10. # [08:15] * Quits: heycam (cam@130.194.73.110) (Quit: bye)
  11. # [08:28] * Joins: heycam (cam@130.194.221.3)
  12. # [08:36] * Quits: heycam (cam@130.194.221.3) (Quit: bye)
  13. # [08:39] * Joins: heycam (cam@130.194.221.3)
  14. # [08:45] * Joins: timeless (timeless@65.75.195.122)
  15. # [09:09] * Joins: Marcos (Marcos@213.236.208.247)
  16. # [09:24] * Joins: tlr (tlr@128.30.52.28)
  17. # [09:28] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  18. # [09:41] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  19. # [09:51] * Joins: anne (annevk@213.236.208.22)
  20. # [10:13] * Joins: Marcos_ (Marcos@213.236.208.247)
  21. # [10:13] * Quits: Marcos (Marcos@213.236.208.247) (No route to host)
  22. # [10:14] * Joins: arve (arve@213.236.208.22)
  23. # [10:18] * Quits: heycam (cam@130.194.221.3) (Quit: bye)
  24. # [11:09] * Joins: heycam (cam@124.168.17.176)
  25. # [11:11] * Quits: Marcos_ (Marcos@213.236.208.247) (Quit: Marcos_)
  26. # [11:16] * Joins: Marcos (Marcos@213.236.208.247)
  27. # [11:21] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  28. # [11:34] * Joins: Lachy (Lachlan@213.236.208.22)
  29. # [11:34] <Hixie> what is this discussion of <access> about?
  30. # [11:34] <Hixie> is it a widget thing?
  31. # [11:34] <Hixie> or is it something i care about?
  32. # [11:36] <anne> maybe both
  33. # [11:37] <anne> widgets has such an element and it clashes with http://www.w3.org/TR/xhtml-access/ which is something PF and others from WAI are advocating now and then
  34. # [11:38] <anne> though I suppose they're mostly silent about it until it reaches REC and will then try to get it into UAs and such similar to how RDFa happened, but maybe not, we'll see :)
  35. # [11:40] <Hixie> holy crap
  36. # [11:41] <Hixie> xhtml-access takes all the problems of accesskey, combines them with the problems of qnames-in-content, and introduces the ability to have platform-inconsistent UI behaviour
  37. # [11:41] <Hixie> all at the same time
  38. # [11:41] <Hixie> that's fantastic
  39. # [11:52] <tlr> hixie, the one thing you'll care about (which I think is only loosely related to access) is how widgets will eventually deal with origins and base uris
  40. # [11:52] <tlr> and no, the widget access thing *is* separate from xhtml-access
  41. # [11:53] <Hixie> widgets as far as i can tell are native apps, not web content, so i'm not really worried about any aspect of them
  42. # [11:53] <Hixie> not that i have anything against them
  43. # [11:54] <Hixie> i just don't have the bandwidth to worry about them
  44. # [11:54] <tlr> My suspicion is that they will blur with web content within relatively few years.
  45. # [11:54] <Hixie> i doubt it
  46. # [11:54] <Hixie> how do you see them doing so?
  47. # [11:55] <tlr> (a) being executed in the same runtime environment
  48. # [11:55] <tlr> (b) perhaps being executed off a web page
  49. # [11:55] <tlr> (c) perhaps ending up as the framework for web apps' access to things like address books and microphones
  50. # [11:56] <tlr> The minimum requirement I have for the widget model (in terms of origin and all that) is that I want to be able to think of a widget as a navigation context (or whatever you call it these days), and still have the html5 security model make sense.
  51. # [11:56] <Hixie> if you mean browsing context, i don't think we've ever called them anything but browsing context
  52. # [11:56] <tlr> yep, browsing context
  53. # [11:56] <Marcos> hixie: http://dev.w3.org/2006/waf/widgets/#the-access-element
  54. # [11:57] <tlr> (sorry, it's been a while that I looked into that part. )
  55. # [11:57] <Hixie> i thought widgets were native apps, security-wise?
  56. # [11:57] <Hixie> has that changed?
  57. # [11:57] <Marcos> no
  58. # [11:57] <Marcos> yes
  59. # [11:57] <Hixie> i thought they had, like, access to the filesystem and so forth
  60. # [11:57] <Marcos> widgets are both
  61. # [11:57] <Marcos> hixie, no access is access to resources on the interwebz
  62. # [11:57] <Marcos> or any URI
  63. # [11:58] <Hixie> i'm confused
  64. # [11:58] <Hixie> how is a widget different from a web page then?
  65. # [11:58] <Marcos> widget signed, packaged
  66. # [11:58] <tlr> (a) different notions of identity
  67. # [11:58] <Marcos> and that
  68. # [11:59] <tlr> (b) separate instances are separate trust domains
  69. # [11:59] <tlr> therefore the proposal to use synthetic origins
  70. # [11:59] <Marcos> oh, we are talking about that
  71. # [11:59] <Hixie> why not just do what safari does with dashboard widgets now, and allow any web page to be turnd into a widget? that has the same end-user result, no?
  72. # [12:00] <Hixie> without any new specs needed
  73. # [12:00] * tlr chuckles. I'd actually like to get there.
  74. # [12:00] <Hixie> we are there
  75. # [12:00] <Hixie> safari's alread shipped that for years
  76. # [12:00] * Hixie slides a 'y' in there
  77. # [12:01] <tlr> safari is there, but the rest of the world isn't.
  78. # [12:01] <Marcos> I'm sure they are just adding an iframe or something to do that
  79. # [12:01] <tlr> Plus, people indeed see widgets as native apps, and want to build app stores around that.
  80. # [12:02] <tlr> therefore, what's interesting here is the tension between that kind of business model (with requisit requirements) and the "let's take a web page and run it without chrome" approach.
  81. # [12:02] <Hixie> Marcos: they just crop a browser window basically
  82. # [12:02] <Marcos> Hixie: yep
  83. # [12:02] <Hixie> no widget spec needed
  84. # [12:02] * Marcos deletes widget spec, resigns as editor
  85. # [12:02] <hendry> :)
  86. # [12:02] * tlr grins, takes spec, renames as "web application packaging"
  87. # [12:03] <Hixie> Marcos: well my point is i don't understand what the widget spec does that's useful, given what you've said about the security model. what's the point? i assume there is one!
  88. # [12:03] <hendry> Hixie: have you seen my blog? http://dabase.com/blog/Widgets_are_simple_offline_packages/
  89. # [12:03] <Marcos> Hixie, ok, lets say. Widgets are native apps.
  90. # [12:04] <Marcos> They provide access to APIs beyond HTML5
  91. # [12:04] <Marcos> APIs are the ones developed by BONDI and others
  92. # [12:04] <tlr> precisely, re additional APIs. That's where the security model is likely to diverge (or be done first for widgets, and make it to web apps later)
  93. # [12:05] <Hixie> hendry: offline web apps are no more immature than widgets; no less fully defined; your third bullet point doesn't seem to be a reason either way; and synchronisation of user data is hard with widgets too
  94. # [12:05] <Hixie> gaaah, BONDI
  95. # [12:05] <Hixie> run away!!!
  96. # [12:05] <Marcos> you know you love it :D
  97. # [12:05] <hendry> Hixie: dude I work on BONDI
  98. # [12:05] <Hixie> sorry to hear that
  99. # [12:05] <Marcos> eheh
  100. # [12:06] <hendry> Hixie: i don't widgets are met to by synced ?
  101. # [12:06] * hendry puts in a 'think' in there somewhere
  102. # [12:06] <Hixie> hendry: well if you don't need syncing, then offline web apps aren't any harder
  103. # [12:07] <hendry> Hixie: offline web apps implies sync to me. but i guess you're right
  104. # [12:07] <Hixie> offline web apps is just a packaging mechanism
  105. # [12:07] <Marcos> Hixie: we provide updates. And I guess that would work with HTML5 sync
  106. # [12:07] <Hixie> the manifest autoupdates resources from the web
  107. # [12:08] <hendry> Hixie: Don't understand ... what is the package?
  108. # [12:08] <tlr> hendry, a collection of resources from the web
  109. # [12:08] <Hixie> right
  110. # [12:08] <Marcos> hendry: is a "logical" package
  111. # [12:08] <hendry> tlr: is it a zip or a tar ball that i could archive offline?
  112. # [12:08] <tlr> it is a collection of resources that you could archive offline
  113. # [12:08] <Hixie> right
  114. # [12:08] <hendry> as a tar ball or zip or anything? what what?
  115. # [12:09] <Marcos> Lets get back to talking about access? :)
  116. # [12:09] <Marcos> (now that Hixie is convinced that widgets are awesome)
  117. # [12:10] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  118. # [12:11] <Marcos> the <access uri=""> element lets you basically do cross domain
  119. # [12:13] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  120. # [12:17] <tlr> it lets a widget declare that it wants to do cross domain
  121. # [12:19] * Marcos pictures Hixie reading the widget spec and running around his house shouting "this is great!" :P
  122. # [12:20] <Hixie> why can't it just do cross-domain anyway
  123. # [12:20] <Hixie> i'm confused
  124. # [12:20] <Marcos> because we don't allow it.
  125. # [12:20] <Marcos> You have to declare every domain you want to access
  126. # [12:22] <Hixie> why?
  127. # [12:22] <Hixie> that seems... odd
  128. # [12:22] <Hixie> can't these widgets run arbitrary binary code?
  129. # [12:22] <Marcos> Hixie, that's like asking why can't web pages just do cross domain.
  130. # [12:23] * tlr notes that that's the actual oddity for dashboard widgets; however, TR/widget widgets probably aren't supposed to.
  131. # [12:23] <Marcos> (well, they can, thanks to script and img)
  132. # [12:23] <Marcos> but anyway, that, we are plugging that hole in widgets
  133. # [12:23] <Marcos> hixie, that's why you need to declare
  134. # [12:23] <Marcos> what domain you want to access
  135. # [12:23] <tlr> marcos, Hixie's point is that *if* (like the dashboard) you permit binary code plugins in a widget, *then* all bets are off.
  136. # [12:24] <Hixie> Marcos: web pages can just do cross-domain
  137. # [12:24] <Hixie> i'm very confused
  138. # [12:24] <Marcos> widgets can't do cross domain
  139. # [12:24] <Hixie> what's the point of making this more secure than web pages, if the user has to install them anyway
  140. # [12:25] * tlr notes that you're talking cross-purpose as as what you mean by "do cross-domain" is concerned.
  141. # [12:25] <Hixie> the user has to go to a web page to do it, right? so they've already been exposed to cross-domain...
  142. # [12:25] <Marcos> no, they got it over bluetooth
  143. # [12:25] * tlr drops a "far" between "as as"
  144. # [12:26] <Hixie> people still use bluetooth?
  145. # [12:26] <Hixie> what kind of device is this meant for?
  146. # [12:26] <Marcos> lets say, as series 60 device
  147. # [12:28] <Hixie> series 60 devices can't browse the web??
  148. # [12:28] <Marcos> ha! you've not used Opera?
  149. # [12:28] <Hixie> yes but opera didn't use bluetooth to visit web pages!
  150. # [12:28] <Hixie> i'm even more confused now
  151. # [12:29] <Marcos> Hixie, I get the widget over bluetooth
  152. # [12:29] <Marcos> I browse the web over GPRS
  153. # [12:29] <Marcos> Widget uses GPRS to access network
  154. # [12:30] <Marcos> get it?
  155. # [12:30] <Marcos> (or I got the widget over BitTorrent)
  156. # [12:32] <Hixie> why don't you just get the widget from GPRS?
  157. # [12:32] <tlr> hixie, app store use case
  158. # [12:33] <tlr> domain from which you got widget is separate from anything that would identify the widget's author usefully
  159. # [12:34] <Marcos> hixie, the point is that we can't say where widgets will come from. We want them to come from anywhere, not just HTTP
  160. # [12:34] <Marcos> Hence we package them using Zip
  161. # [12:35] <Marcos> If they are sent over HTTP, they are labelled with the appropriate content type ("application/widget")
  162. # [12:35] <Marcos> otherwise, anything goes and it need to work
  163. # [12:35] <Marcos> so zip is the easiest, most interop. thing to use
  164. # [12:36] <Hixie> tlr: when i buy an app from the apple or android app stores, the app comes over the same connection as the web...
  165. # [12:36] <Marcos> Hixie, over HTTP?
  166. # [12:36] <tlr> hixie, for all intents and purposes, these app stores are transparent proxies for arbitrary crap
  167. # [12:36] <Marcos> by crap he means widgets :D
  168. # [12:36] <Hixie> Marcos: i still don't understand why these apps have to be more secure than a web page
  169. # [12:37] <tlr> and I *really* don't want to give a widget full access to an app store where CSRF means loss of money.
  170. # [12:37] <Marcos> Hixie, because we have an opportunity to patch a few holes. We should take them
  171. # [12:37] <tlr> hixie, see above, I think you're largely talking cross purposes when you say "do cross-domain"
  172. # [12:38] <Hixie> tlr: quite possible
  173. # [12:38] <tlr> my understanding is that <access> does *not* affect inline elements, for example
  174. # [12:38] <tlr> ... but rather replaces the same origin policy for something like XHR
  175. # [12:38] <Hixie> anyway
  176. # [12:38] <Hixie> as i said, this isn't the web, so i really don't have the bandwidth to worry
  177. # [12:38] <Marcos> Hixie, sorry, it is the web
  178. # [12:38] <Hixie> if it's the web, stop plugging holes and just use the web
  179. # [12:38] * tlr mumbles "film at 11" and waits for hixie and Marcos to throw spiders at each other
  180. # [12:39] * Marcos notes his is rubber and Hixie is glue :)
  181. # [12:39] <Marcos> s/his/he's
  182. # [12:40] <Marcos> Hixie, point taken. Problem is that widgets don't have an origin
  183. # [12:40] <Hixie> it seems to me you want it both ways -- but you can't be the web if you're not actually using the web's concepts, security model, apis, etc
  184. # [12:41] <Hixie> bondi isn't the web
  185. # [12:41] * Joins: darobin (robinb@82.233.247.234)
  186. # [12:41] <Hixie> not having an origin isn't the web
  187. # [12:41] <Hixie> having a different security model isn't the web
  188. # [12:41] <Marcos> ok, we are not the Web. You are right.
  189. # [12:41] <Hixie> :-)
  190. # [12:41] * Marcos allows Hixie to go free and not worry about widgets :)
  191. # [12:41] <Hixie> :-)
  192. # [12:42] <tlr> for the record, I dare a bet that "offline webapps 2.0" and "widgets 2.0" will be the same thing.
  193. # [12:43] <Marcos> but be warned, Hixie, widgets will crop up on the Web so it might be in your interest to take a peak a the spec and send some comments.
  194. # [12:43] <Hixie> i don't understand how to give comments, because i don't understand what widgets do that the web doesn't already do
  195. # [12:44] * Marcos starts to worry :(
  196. # [12:44] <darobin> widgets *are* native apps
  197. # [12:44] <darobin> they're just native apps for which people want to control some aspects of what they have access to
  198. # [12:44] * tlr starts to stop worrying and love the bomb
  199. # [12:44] <Hixie> well then they won't crop up on the web :-)
  200. # [12:45] <Hixie> native apps are fundamentally incompatible with the web security model
  201. # [12:45] <darobin> agreed
  202. # [12:45] <Hixie> Marcos doesn't seem to :-)
  203. # [12:45] * Marcos agrees
  204. # [12:45] <Marcos> now
  205. # [12:45] <darobin> if they do crop up on the web, it'll be as something like ActiveX controls (heh heh) except that you're supposed to get a say in what they can access
  206. # [12:45] <Marcos> you've convinced me that I'm crazy thinking otherwise
  207. # [12:46] <darobin> I think that trying to see widgets in a web context at this stage isn't helpful
  208. # [12:46] <Marcos> agreed
  209. # [12:46] <darobin> it could happen, and it probably won't need a spec actually
  210. # [12:46] <tlr> disagree
  211. # [12:46] <Marcos> widgets are native apps that use HTML and JS and stuff
  212. # [12:46] <darobin> but in the meantime, they're just native apps that use web-based technology, and for which we want a security model that allows people to be selective about what they grant access to
  213. # [12:47] <tlr> perhaps one way to think about them is as web runtimes (*shudder*) with mildly different feature sets and access to local code.
  214. # [12:47] <darobin> what falls out of that is that, indeed, it does make a potential convergence between apps and the web a fair bit easier — but we'll cross that bridge later
  215. # [12:47] <tlr> These beasts may still, e.g., have frames that came directly from the web, and behave just like every frame that comes from a web application willb ehave.
  216. # [12:47] <darobin> tlr: right, but you can already do that with native apps
  217. # [12:48] <tlr> darobin, you can do *everything* with native apps
  218. # [12:49] <tlr> the value proposition is to have a cross-platform development environment
  219. # [12:49] <tlr> which only works because people have to deploy web browsers anyway, and have incentives to reuse code, massively
  220. # [12:49] <tlr> i.e., the value proposition goes downhill in the moment in which you deviate from the web model
  221. # [12:50] <darobin> fair enough
  222. # [12:50] <darobin> but I'm not sure that influences how the spec is crafted
  223. # [12:50] <darobin> as opposed to how we might think about the ecosystem
  224. # [12:51] <Hixie> well having a different security system is a deviation
  225. # [12:51] <Hixie> for what it's worth :-)
  226. # [12:53] <tlr> precisely
  227. # [12:53] <tlr> therefore, the minimum requirement is that the beast must be consistent with the html security model to the extent possible
  228. # [12:54] <tlr> whether it behaves like a sandboxed iframe in that system, or like a web page, is a different question
  229. # [12:57] <darobin> I'd assume same security model with extensions to allow some things to be loosened up
  230. # [12:58] <darobin> what with it being a native app and all :)
  231. # [13:20] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  232. # [13:21] * Quits: arve (arve@213.236.208.22) (Ping timeout)
  233. # [13:28] * Joins: taf2 (taf2@68.49.245.59)
  234. # [13:29] * Joins: ArtB (d0309a43@128.30.52.43)
  235. # [13:46] * Quits: taf2 (taf2@68.49.245.59) (Quit: taf2)
  236. # [13:52] * Quits: Marcos (Marcos@213.236.208.247) (Ping timeout)
  237. # [13:55] * Joins: arve (arve@213.236.208.22)
  238. # [13:57] * tlr is now known as tlr-bbl
  239. # [14:03] * Quits: arve (arve@213.236.208.22) (Ping timeout)
  240. # [14:04] * Joins: Marcos (Marcos@213.236.208.247)
  241. # [14:07] * Quits: Marcos (Marcos@213.236.208.247) (Ping timeout)
  242. # [14:18] * Joins: taf2 (taf2@65.210.82.235)
  243. # [14:20] * Joins: arve (arve@213.236.208.247)
  244. # [14:23] * Joins: Marcos (Marcos@213.236.208.22)
  245. # [14:48] * Quits: gsnedders (gsnedders@86.136.52.180) (Client exited)
  246. # [14:59] * Joins: chaals (chaals@89.130.83.193)
  247. # [14:59] * Joins: aroben (aroben@71.58.77.15)
  248. # [15:05] * Quits: arve (arve@213.236.208.247) (Ping timeout)
  249. # [15:09] * Joins: arve (arve@213.236.208.247)
  250. # [15:18] * tlr-bbl is now known as tlr
  251. # [15:21] * Quits: chaals (chaals@89.130.83.193) (Client exited)
  252. # [15:28] <ArtB> Marcos, is there a place for Versioning in the Widgets V2 wiki (http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R)? Or do see it as No/Never ?
  253. # [15:29] <Marcos> ArtB: never
  254. # [15:29] <Marcos> not for the lang
  255. # [15:30] * Quits: arve (arve@213.236.208.247) (Ping timeout)
  256. # [15:36] * Joins: arve (arve@213.236.208.247)
  257. # [15:36] * Quits: arve (arve@213.236.208.247) (Quit: Ex-Chat)
  258. # [15:41] * tlr is now known as tlr-brb
  259. # [16:28] * Quits: Marcos (Marcos@213.236.208.22) (Ping timeout)
  260. # [16:34] * Joins: Marcos (Marcos@213.236.208.247)
  261. # [17:21] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  262. # [17:48] * Joins: gsnedders (gsnedders@86.136.52.180)
  263. # [17:54] * Quits: darobin (robinb@82.233.247.234) (Ping timeout)
  264. # [18:21] * tlr-brb is now known as tlr
  265. # [18:29] * Quits: Marcos (Marcos@213.236.208.247) (Quit: Marcos)
  266. # [18:35] * Joins: Marcos (Marcos@213.236.208.22)
  267. # [19:08] * Quits: taf2 (taf2@65.210.82.235) (Quit: taf2)
  268. # [19:30] * Joins: taf2 (taf2@65.210.82.235)
  269. # [19:57] * Quits: Marcos (Marcos@213.236.208.22) (Quit: Marcos)
  270. # [20:12] * Joins: aroben_ (aroben@71.58.77.15)
  271. # [20:14] * Quits: aroben (aroben@71.58.77.15) (Ping timeout)
  272. # [20:23] * Joins: Lachy (Lachlan@85.196.122.246)
  273. # [20:31] * Quits: Lachy (Lachlan@85.196.122.246) (Connection reset by peer)
  274. # [20:31] * Joins: Lachy (Lachlan@85.196.122.246)
  275. # [20:52] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  276. # [21:24] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
  277. # [22:42] * Joins: arve (arve@95.34.170.26)
  278. # [23:02] * Joins: Lachy (Lachlan@85.196.122.246)
  279. # [23:49] * Quits: arve (arve@95.34.170.26) (Ping timeout)
  280. # Session Close: Tue Apr 21 00:00:00 2009

The end :)