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

Options:

  1. # Session Start: Tue Jan 27 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [00:42] * Parts: chaals (chaals@89.130.83.193)
  4. # [00:43] * Joins: chaals (chaals@89.130.83.193)
  5. # [02:32] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: Leaving)
  6. # [02:32] * Joins: Lachy (Lachlan@85.196.122.246)
  7. # [04:58] * Joins: billyjackass (MikeSmith@mcclure.w3.org)
  8. # [05:04] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  9. # [05:08] * billyjackass is now known as MikeSmith
  10. # [05:26] * Quits: sicking (chatzilla@63.245.220.242) (Client exited)
  11. # [06:15] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  12. # [06:20] * Quits: hober (ted@206.212.254.2) (Client exited)
  13. # [06:20] * Joins: hober (ted@206.212.254.2)
  14. # [06:33] * Joins: heycam (cam@124.168.42.25)
  15. # [06:44] * Quits: hober (ted@206.212.254.2) (Quit: ERC Version 5.3 (IRC client for Emacs))
  16. # [06:46] * Joins: sicking (chatzilla@63.245.220.242)
  17. # [08:20] * Quits: chaals (chaals@89.130.83.193) (Quit: chaals)
  18. # [09:14] * Quits: marcos (marcos@87.196.212.70) (Quit: marcos)
  19. # [09:28] * Joins: arve (arve@213.236.208.22)
  20. # [09:41] * Joins: tlr (tlr@128.30.52.30)
  21. # [10:05] * Quits: arve (arve@213.236.208.22) (Client exited)
  22. # [10:06] * Joins: arve (arve@213.236.208.22)
  23. # [10:21] * Joins: gsnedders_ (gsnedders@86.136.52.180)
  24. # [10:21] * Quits: gsnedders (gsnedders@86.136.52.180) (Connection reset by peer)
  25. # [10:41] * Quits: anne (annevk@77.163.243.203) (Client exited)
  26. # [10:42] * Joins: anne (annevk@77.163.243.203)
  27. # [11:04] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  28. # [11:12] * Quits: anne (annevk@77.163.243.203) (Client exited)
  29. # [11:12] * Joins: anne (annevk@77.163.243.203)
  30. # [11:42] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  31. # [11:53] * Joins: Lachy (Lachlan@213.236.208.22)
  32. # [11:57] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: Leaving)
  33. # [11:57] * Joins: Lachy (Lachlan@213.236.208.22)
  34. # [12:03] <Lachy> heycam, yt?
  35. # [12:05] <anne> heycam, http://dev.w3.org/2006/webapi/WebIDL/#ImplementedOn does this mean it only takes a single name? what if the members need to be on multiple interfaces?
  36. # [12:06] <Lachy> anne, that's what I was going to ask him ;-)
  37. # [12:06] <heycam> anne, indeed. just listed more than one [ImplementedOn].
  38. # [12:06] <anne> heycam, I think we also need the opposite, e.g. how do I indicate that XMLHttpRequest implements EventTarget?
  39. # [12:06] <heycam> otherwise, the natural syntax [ImplementedOn=A,B] would clash with the list of xattrs
  40. # [12:07] <heycam> anne, you can use inheritance
  41. # [12:07] <Lachy> anne, heycam, I just added ImplementedOn to selectors api
  42. # [12:07] <heycam> Lachy, cool
  43. # [12:07] <heycam> but perhaps an inverse of [ImplementedOn] is needed... thinking about it is on my todo list
  44. # [12:07] <anne> heycam, I suppose inheritance works, is that the cleanest?
  45. # [12:08] <heycam> yeah maybe not
  46. # [12:08] <Lachy> and I removed that prose about treating null and undefined as an empty string since anne and zcorpan convinced me to yesterday that it was redundant
  47. # [12:08] <heycam> it would result in the same prototype chain as inheritance in JS, but java would be different
  48. # [12:08] <heycam> Lachy, oh, cool :-)
  49. # [12:09] <anne> Implements=interface would work
  50. # [12:09] <heycam> yeah, seems like a sensible name
  51. # [12:09] <heycam> probably won't get to working on web idl for another few weeks, so let me know if anything is urgent
  52. # [12:09] <anne> can you tell me more how the natural syntax clashes with xattrs? I don't really follow :)
  53. # [12:09] <heycam> oh
  54. # [12:10] <anne> not urgent, XHR is delayed by Hixie's work on scripting contexts and such in HTML5
  55. # [12:10] <heycam> [ImplementedOn=A,Callback]
  56. # [12:10] <heycam> is Callback an xattr, or an interface name?
  57. # [12:11] <anne> so a) what's an xattr and b) why would it be anything but an interface name for ImplementedOn?
  58. # [12:12] <heycam> xattr = extended attribute, so the main things you put in square brackets
  59. # [12:12] <heycam> e.g. you can do [Callback, Constructor] interface A { ... }
  60. # [12:13] <heycam> and the Constructor isn't an argument, it's a separate extended attribute
  61. # [12:13] <heycam> if you supported [ImplementedOn=A,B,C], then it looks like B and C are extended attribute names
  62. # [12:14] <heycam> of course that can be worked around, with [ImplementedOn=(A,B,C)] e.g., if we wanted to allow that
  63. # [12:15] <anne> ah ok, so now you write [ImplementedOn=A] [ImplementedOn=B] [ImplementedOn=C] ?
  64. # [12:15] <anne> i guess that's good enough
  65. # [12:16] <heycam> yeah
  66. # [12:16] <heycam> though i should check that i allowed that =)
  67. # [12:16] <anne> and maybe make it explicit somehow
  68. # [12:16] <heycam> you'd need [ImplementedOn=A,ImplementedOn=B,ImplementedOn=C]
  69. # [12:17] <heycam> can't have a sequence of [thing]s
  70. # [12:18] <Lachy> heycam, oh. Then I did it wrongly.
  71. # [12:18] <Lachy> heycam, your spec isn't clear about that
  72. # [12:19] <Lachy> oh, maybe not. heycam, see http://dev.w3.org/2006/webapi/selectors-api/#nodeselector
  73. # [12:20] <heycam> yeah you'd need to join those adjacent []s up
  74. # [12:20] <heycam> [ImplementedOn=Document,ImplementedOn=DocumentFragment,ImplementedOn=Element,NoInterfaceObject]
  75. # [12:20] <Lachy> [ImplementedOn=Document,ImplementedOn=DocumentFragment,ImplementedOn=Element,NoInterfaceObject]
  76. # [12:20] <Lachy> yeah
  77. # [12:20] <heycam> feel free to put line breaks after the commas, too
  78. # [12:22] <anne> you know, now the xattr comment makes more sense
  79. # [12:22] <heycam> hmm?
  80. # [12:23] <Lachy> Should I now remove the statement "Objects implementing any of the Document, DocumentFragment or Element interfaces, as defined in DOM Level 3 Core, must also implement the NodeSelector interface. [DOM-LEVEL-3-CORE]"?
  81. # [12:23] <anne> well, due to the concrete example I can see how [ImplementedOn=A,B,C] fails
  82. # [12:23] <Lachy> Or should I replace it with something so that the DOM3Core ref remains?
  83. # [12:24] <heycam> Lachy, yep you could. or say "As required by the IDL blah blah, objects implementing ..."
  84. # [12:24] <anne> Lachy, maybe add a section on dependencies?
  85. # [12:24] <anne> i.e. selectors web idl and dom3core
  86. # [12:24] <anne> or dom2core
  87. # [12:26] <Lachy> I changed it to "The Document, DocumentFragment and Element interfaces referenced from the following IDL are defined in DOM Level 3 Core"
  88. # [12:26] <Lachy> anne, what do you mean?
  89. # [12:27] * heycam is wondering about IDL "includes"
  90. # [12:27] <anne> http://dev.w3.org/2006/webapi/XMLHttpRequest/#dependencies
  91. # [12:28] <anne> heycam, I think ImplementedOn is being (ab)used for that
  92. # [12:28] <anne> see e.g. how the Navigator object in HTML5 and Workers works
  93. # [12:28] <heycam> i'll send mail to the list to see what people think
  94. # [12:29] <anne> Lachy, hope that link helps
  95. # [12:29] <Lachy> ok, I'll think about it
  96. # [12:29] <Lachy> and fix it up after lunch
  97. # [12:30] <anne> ooh, I bought some eggs yesterday :)
  98. # [12:31] * heycam wonders why buying eggs is a big deal? :)
  99. # [12:33] <anne> it's just that I thought of it which means my brunch is slightly better than normal
  100. # [12:34] <heycam> yum :)
  101. # [12:39] * Joins: ArtB (ce846302@128.30.52.43)
  102. # [12:40] <anne> so I now have "Objects implementing the <code>Document</code> interface, as defined in DOM Level 3 Core, <em class="ct">must</em> also implement the <code>DocumentView</code> interface." replacing that with ImplementedOn=Document seems right, right?
  103. # [12:41] <heycam> yeah with the caveat pointed out in my mail to public-webapps just now
  104. # [12:45] <anne> cheers
  105. # [12:45] <heycam> so at the moment, the IDL is non-conforming because Document isn't anything that's declared previously
  106. # [12:46] <anne> yeah ok
  107. # [12:46] <anne> I think we should make things as simple and straightforward as we can
  108. # [12:46] <heycam> right
  109. # [12:47] <anne> at least as far extensions to the dom module go
  110. # [12:47] <anne> I don't care much about other modules atm :)
  111. # [12:47] <heycam> heh
  112. # [12:48] <Lachy> anne, I already reference WebIDL and Selectors from the Conformance Requirements section. I don't think I need to introduce a whole new Dependencies section.
  113. # [12:48] <heycam> ok, /me goes to bed, cursing dokic's loss to safina
  114. # [12:49] <Lachy> However, I could add a statement like this to that section: "Interfaces used in, but not defined by, this specification are defined in DOM Level 3 Core."
  115. # [12:50] <Lachy> and then perhaps list the 4 interfaces used
  116. # [12:53] <anne> HTML5 duplicates information as well, e.g. in http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#documents-in-the-dom
  117. # [12:54] <anne> I suppose that still needs fixing
  118. # [12:55] <Lachy> anne, how's this? http://dev.w3.org/2006/webapi/selectors-api/#terminology
  119. # [12:56] <Lachy> oh, I should do that for exceptions too
  120. # [12:56] <arve> ArtB: we probably want to drop this from widget-landscape:
  121. # [12:56] <arve> Media type:
  122. # [12:56] <arve> An [media type] that formally associates a widget resource with some proprietary widget user agent. For example, Joost's widget engines requires that widgets be served over HTTP with a application/vnd.joost.joda-archive media type.
  123. # [12:56] <arve> joost widgets don't exist any more
  124. # [13:00] <arve> another question:
  125. # [13:00] <arve> ByteArray -- is that going to be specified anywhere?
  126. # [13:02] <anne> it sort of depends on whether we think bytes should be done in ES
  127. # [13:02] <anne> what is currently named CanvasPixelArray might be an interesting alternative
  128. # [13:04] <arve> anne: context is really File I/O
  129. # [13:04] <arve> which I hope will be picked up soon
  130. # [13:04] <arve> and harmonised with file upload
  131. # [13:05] <arve> read: merged in some sensible manner
  132. # [13:05] <anne> still, if we need byte access CanvasPixelArray might be interesting as it does provide a ByteArray under a different name
  133. # [13:06] <arve> canvaspixelarray also has some implied behavior
  134. # [13:06] <arve> overall, I think it should be renamed
  135. # [13:07] <anne> sure, just wondering if it's the right representation
  136. # [13:08] <anne> if it is we can try to take it out of HTML5 and have XHR etc. use it
  137. # [13:09] <arve> While I, ideally, think that it belongs in ES 262 3.1, ECMA works at a sub-glacial pace
  138. # [13:20] <ArtB> Arve, re the Widget Landscape doc, I don't think Marcos has touched that doc in months
  139. # [13:20] * ArtB goes to check ...
  140. # [13:21] <ArtB> Arve, 5 months ago
  141. # [13:22] <ArtB> My recollection is he wanted to complete it in 1Q-09 and it would be published as a "Working Group Note" i.e. not a WD
  142. # [13:39] <tlr> what's the current status of FileIO, and current draft?
  143. # [13:40] <tlr> anne?
  144. # [13:40] <tlr> artb?
  145. # [13:40] <tlr> arve
  146. # [13:43] <ArtB> tlr, I don't have a lot more to say about the status than what is summarized in http://www.w3.org/2008/webapps/wiki/PubStatus
  147. # [13:44] <arve> tlr: current is what chaals submitted on behalf of Opera
  148. # [13:44] <tlr> ok, so it's "proposal under consideration"
  149. # [13:44] <tlr> no draft with any official standing
  150. # [13:44] <tlr> works for me
  151. # [13:44] <arve> correct
  152. # [13:44] <arve> tlr: oops
  153. # [13:45] <tlr> ?
  154. # [13:45] <arve> I'll send you a link to slides later today
  155. # [13:45] <tlr> oh, am I still missing your slides from December?
  156. # [13:46] <ArtB> tlr, the Web API WG published File Upload spec in Oct 2006: http://www.w3.org/TR/file-upload/
  157. # [13:48] <tlr> so, Oct 2006 doesn't precisely sound like active development
  158. # [13:48] <tlr> I guess what I hear is "unclear where this space goes", which simply means that File IO isn't a good API example to cite (which is all this request is about)
  159. # [14:01] <anne> tlr, Arun said he would get to it by the end of this month
  160. # [14:02] <anne> tlr, get something out, even
  161. # [14:02] <tlr> for the purposes of what I'm working on right now, it's just this: <li>File IO (<a
  162. # [14:02] <tlr> href="http://lists.w3.org/Archives/Public/public-webapi/2008May/0065.html">proposed</a> to
  163. # [14:02] <tlr> the <a href="http://www.w3.org/2008/webapps/">W3C Web Applications</a> Working Group)</li>
  164. # [14:02] <anne> oh, that specification, dunno about that
  165. # [14:02] <anne> sorry
  166. # [14:03] <tlr> np; thanks for help
  167. # [14:03] <tlr> I think I have all I need right now
  168. # [14:05] <anne> kk
  169. # [14:10] <ArtB> TLR, Mike, Doug, Chaals and I are trying to have a coord call this week and the questions you asking re File I/O versus File Upload are one of the topics I'd like to discuss
  170. # [14:11] <ArtB> I don't think that call is going to happen before Friday (Jan 30)
  171. # [14:11] <tlr> art, my interest in FileIO is (exclusively) that it has come up as an illustrative example
  172. # [14:11] <ArtB> where the context is the Security WS Report?
  173. # [14:11] <tlr> so, for my purposes, what matters right now is that I put the right link and status into that report. I have no stake in where the spec goes.
  174. # [14:11] <tlr> But thanks for the heads-up.
  175. # [14:11] <tlr> ack
  176. # [14:26] <arve> file io is IMO also a part of the hornet nest that is widget/whatever protocol
  177. # [14:32] * tlr is now known as tlr-bbl
  178. # [15:21] * tlr-bbl is now known as tlr
  179. # [16:08] * Joins: aroben (aroben@71.58.73.153)
  180. # [16:16] * Joins: arve_ (arve@213.236.208.22)
  181. # [16:16] * Quits: arve_ (arve@213.236.208.22) (Quit: Leaving)
  182. # [16:19] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  183. # [16:51] * Quits: gsnedders_ (gsnedders@86.136.52.180) (Quit: gsnedders_)
  184. # [16:58] * Joins: marcos (marcos@87.196.212.70)
  185. # [16:59] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Client exited)
  186. # [17:19] * Joins: gsnedders (gsnedders@86.136.52.180)
  187. # [18:16] * Quits: arve (arve@213.236.208.22) (Ping timeout)
  188. # [18:48] * Joins: hober (ted@206.212.254.2)
  189. # [19:00] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  190. # [19:22] * Joins: Lachy (Lachlan@85.196.122.246)
  191. # [20:31] * Joins: arve (arve@95.34.27.22)
  192. # [20:31] <ArtB> marcos, yt?
  193. # [20:55] <arve> I thought he was on route to .au by now?
  194. # [20:56] <ArtB> arve, thanks
  195. # [20:56] <arve> I might be wrong, though
  196. # [20:57] <ArtB> I'm going to work on the Widgets agenda later today or tomorrow and wanted to know his availability for jan 29
  197. # [20:59] * Joins: plh (plh@128.30.52.28)
  198. # [21:08] <ArtB> arve, yt? I have some comments about the Widgets API & Events spec. Want to discuss them here on the mail list?
  199. # [21:08] <ArtB> s/on the/or the/
  200. # [21:09] <arve> drop them here
  201. # [21:09] <arve> I've been doing a bit of work on it since last teleconf
  202. # [21:09] <ArtB> Abstract - the text about HTML5 is a bit confusing and perhaps not particularly relevant for a high level Abstract. If anything at all must be said at this point in the document re HTML5 (and I recommend it be removed), I would just say something like "The specification describes the Widget interface and other dependencies, including:" and remove the "Persistent storage" bullet.
  203. # [21:10] <arve> ArtB: I think I've dropped it already
  204. # [21:10] <arve> (Not checked in yet, though)
  205. # [21:10] <arve> I think I'm removing any and all reference to HTML5
  206. # [21:10] <ArtB> :)
  207. # [21:10] <arve> on that note, I think I'll reintroduce set/getPreference again
  208. # [21:11] <ArtB> Re section 1. - Marcos agreed to provide test for the Introduction, right?
  209. # [21:11] <ArtB> Re Section 1.1 - I would remove the following sentence until the document actually exists:"The Widgets 1.0: Security Model [Widgets-Security] specification defines a security model that defines what a widget can or cannot do at runtime."
  210. # [21:12] <arve> ArtB: For the introduction, I'm basically thinking lifting most of the widget one
  211. # [21:12] <arve> it's completely generic
  212. # [21:12] <arve> I have some comments for widgets-landscape that we should address
  213. # [21:13] <ArtB> what do you mean by "lifting most of the widget one"?
  214. # [21:13] <arve> s/widget/p&c/
  215. # [21:13] <ArtB> ok; make sense
  216. # [21:13] <arve> the p&c doesn't actually introduce p&c specifically
  217. # [21:14] <ArtB> re landscape doc; sounds good; IMO, it's pretty low priority though I recognize Marcos may not agree with me :)
  218. # [21:15] <ArtB> Section 2 - I don't understand the sentence in the Red Block "Pending a stronger definition of view states, icons, definitions of mode change events and view states is left undescribed."
  219. # [21:15] <ArtB> I can think of at least two interpretations
  220. # [21:17] <ArtB> Do you mean something "Currently, this document does not have a good definition of view states. Consequently, icons, the definitions of mode change events and view states are undefined."?
  221. # [21:19] <ArtB> Re Section 2.2 - the sentence in the 3rd paragraph isn't complete. NB "... separate widget instances to ".
  222. # [21:19] <arve> 2.2 3rd: already changed, IIRC
  223. # [21:19] <ArtB> but you're going to delete 2.2 (reference is version 1.6)?
  224. # [21:21] <ArtB> Re Section 2.3 missing definitions for: the 4 VIEW_* constants, currentMode, onModeChange, preferences, onbeforeupdate, onafterupdate, and hasFeature
  225. # [21:21] <ArtB> Re Section 2.3 - Section 2.3 - is it a problem for this interface to have both WidgetIconCollection icons and Array icons?
  226. # [21:21] <ArtB> Re Section 2.3 - duplicate definition of "void setIcon(in DOMString url);"
  227. # [21:21] <arve> 2.2 is going
  228. # [21:21] <arve> gone
  229. # [21:22] <ArtB> awesome!
  230. # [21:22] <ArtB> Re Section 2.3 - definition of WidgetIconCollection is missing
  231. # [21:22] <arve> 2.3, yes
  232. # [21:22] <arve> I might change that to just Array, though
  233. # [21:22] <arve> (widgeticon
  234. # [21:22] <arve> setIcon is a typo, because I was planning on allowing either a WidgetIcon object, or a URL
  235. # [21:23] <arve> the VIEW_ constants: gone, and current mode has been defined to be a DOMString instead
  236. # [21:23] <arve> onModeChange is getting a definition in line with what Mark Priestley has proposed
  237. # [21:27] <ArtB> when will check-in your local changes, Arve?
  238. # [21:33] <arve> ArtB: sometime tomorrow, I guess
  239. # [21:34] <ArtB> please ping me after your checkin
  240. # [21:34] <arve> I still have items from timeless and Jere Kapyaho
  241. # [21:53] * Quits: arve (arve@95.34.27.22) (Quit: Leaving)
  242. # [22:39] * Parts: plh (plh@128.30.52.28) (Ex-Chat)
  243. # [22:42] * Quits: heycam (cam@124.168.42.25) (Quit: bye)
  244. # [23:19] * Joins: heycam (cam@130.194.72.84)
  245. # Session Close: Wed Jan 28 00:00:00 2009

The end :)