/irc-logs / w3c / #webapps / 2009-02-02 / end

Options:

  1. # Session Start: Mon Feb 02 00:00:01 2009
  2. # Session Ident: #webapps
  3. # [00:09] * Joins: heycam (cam@130.194.72.84)
  4. # [01:53] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  5. # [02:09] * Joins: gavin__ (gavin@63.245.208.169)
  6. # [02:09] * Quits: gavin (gavin@63.245.208.169) (Connection reset by peer)
  7. # [03:28] * Joins: heycam (cam@130.194.72.84)
  8. # [04:47] * gavin__ is now known as gavin
  9. # [05:43] * Quits: shepazu (schepers@128.30.52.30) (Client exited)
  10. # [05:44] * Joins: shepazu (schepers@128.30.52.30)
  11. # [06:32] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  12. # [07:17] * Joins: heycam (cam@124.168.33.158)
  13. # [09:03] * Joins: tlr (tlr@128.30.52.30)
  14. # [09:28] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  15. # [10:25] * Joins: arve (arve@213.236.208.22)
  16. # [10:47] * Joins: anne (annevk@213.236.208.22)
  17. # [10:52] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  18. # [11:05] * Quits: arve (arve@213.236.208.22) (Client exited)
  19. # [11:06] * Joins: Lachy (Lachlan@213.236.208.22)
  20. # [11:07] * Joins: arve (arve@213.236.208.22)
  21. # [13:02] * Joins: ArtB (ce846302@128.30.52.43)
  22. # [13:08] <marcos> Arve, I wondering what happened to using HTML5 Storage interface in the API spec?
  23. # [13:29] <arve> marcos: I ripped it out, and reintroduced our own on purpose, given that it's fairly impossible to refer to HTML5 normatively
  24. # [13:29] <arve> (There are also implementation concerns)
  25. # [13:31] <marcos> ok. Anil form MS also had concerns about storage because of it's dependency on origin.
  26. # [13:31] <anne> why is it impossible? several specs do it
  27. # [13:32] <marcos> Anne, which specs?
  28. # [13:32] <anne> you can just say that a widget has its own unique origin, you prolly need to say something about that anyway to interact with HTML features
  29. # [13:32] <anne> XHR, Web Workers, several of the more recently splitted out parts of HTML5
  30. # [13:32] <marcos> yeah, that's what I was thinking also
  31. # [13:33] <marcos> origin just needs to be some URI right?
  32. # [13:34] * arve recognizes «some URI» as contentious
  33. # [13:34] * marcos tries to put the square widget:// or tag:// square peg into the origin hole :D
  34. # [13:37] <anne> it's either a scheme, hostname, port tuple or an identifier of some sorts
  35. # [13:42] <arve> marcos: that's what I was getting at
  36. # [13:44] <anne> arve, you need to resolve the issue somehow, otherwise e.g. URI resolving and <iframe> etc. will fail
  37. # [13:44] <anne> and scripting won't work, etc.
  38. # [13:44] <anne> origin is not just needed for localStorage
  39. # [13:44] <anne> most stuff depends on it
  40. # [13:48] * Quits: arve (arve@213.236.208.22) (Quit: Leaving)
  41. # [13:49] * Joins: arve (arve@213.236.208.22)
  42. # [13:52] * Quits: arve (arve@213.236.208.22) (Client exited)
  43. # [13:52] <marcos> amen
  44. # [13:58] * Joins: arve (arve@213.236.208.22)
  45. # [14:04] <ArtB> marcos, yt?
  46. # [14:04] <marcos> ye
  47. # [14:04] <marcos> p
  48. # [14:05] <ArtB> the API & Events spec defines generic {get,set}Preferences APIs so the user agent can get/set all of the metadata in the config file, rigth?
  49. # [14:07] <marcos> no
  50. # [14:07] <ArtB> or is the idea the conf file's predefined metadata is retrieved from the attributes?
  51. # [14:07] <marcos> yes
  52. # [14:07] <marcos> Though, option 1 would have been more extensible
  53. # [14:08] <marcos> option 1 being get/set as you mentioned
  54. # [14:08] <ArtB> If someone wants to extend the config file, e.g. to add their own key+value pairs, how is that done?
  55. # [14:08] <ArtB> define their own element in their own NS?
  56. # [14:09] <marcos> through a namespace. however, then there is no mechanism for accessing those values at runtime
  57. # [14:10] <ArtB> Perhaps there is a need for app-specicif or Widget-specific name+value support in the config file
  58. # [14:10] <ArtB> <feature> seems kinda close
  59. # [14:10] <marcos> you mean for setting preferences?
  60. # [14:11] <ArtB> any of the widget's metadata
  61. # [14:12] <ArtB> I'm thinking about widget-specific settings
  62. # [14:12] <marcos> hmmm.... wonder if you could use xhr to get you the config document and then use getElementsByTagNameNS?
  63. # [14:12] <ArtB> how does the author state those?
  64. # [14:13] <ArtB> need something in the config file - config does mean configuration i.e. settings
  65. # [14:13] <marcos> sorry, I'm a bit lost :( Lets take a step back. What do you mean by widget-specific settings?
  66. # [14:13] <ArtB> <setting name="some_name" value=
  67. # [14:14] <ArtB> oops, let me try again
  68. # [14:14] <ArtB> <setting name="some_name" value="some_value"/>
  69. # [14:14] <marcos> these settings, would they be used at runtime by the start file?
  70. # [14:14] <ArtB> then getPreference("some_name") returns "some_value"
  71. # [14:15] <ArtB> they would be used by the widget engine
  72. # [14:15] <marcos> ok, the way I was thinking that would work was like this:
  73. # [14:15] <ArtB> The current mode appears to this:
  74. # [14:15] <ArtB> <vendor:setting name="some_name" value="some_value"/>
  75. # [14:18] <marcos> In javascript, the author would check if a preference exists.
  76. # [14:18] <marcos> <html>
  77. # [14:18] <marcos> <script>
  78. # [14:18] <marcos> /check if prefs have been initialized
  79. # [14:18] <marcos> if(!preferences.getPreference('somePref')){
  80. # [14:18] <marcos> preferences.setPreference('somePre','someValue');
  81. # [14:18] <marcos> preferences.setPreference('somePre2','someValue2');
  82. # [14:18] <marcos> etc.
  83. # [14:18] <marcos> }
  84. # [14:18] <marcos> </script>
  85. # [14:19] <marcos> my rationale was to keep code where the code is, and away from the configuration side of things.
  86. # [14:22] <marcos> From my point of view, this is less annoying for developers as it means that they only set preferences in one place
  87. # [14:23] <ArtB> I see your point. But OTOH, having the settings/prefs/config-data in the declarative format make sense too
  88. # [14:24] <marcos> it does, I agree. But I don't see any advantage.
  89. # [14:30] <marcos> Having things that are used in code (preferences) being declare in the configuration document still seems like a big pain to me. It just replicates functionality.
  90. # [14:31] <ArtB> YA example of more than one way to "skin a cat" :)
  91. # [14:32] <ArtB> btw, have you received any requests to extend the LCWD comment period?
  92. # [14:32] <marcos> no, I have not
  93. # [14:34] <marcos> I'm pretty happy with the current reviews. However, it would be good if we could get an Anne or a Lachy to go through it and rip it apart (hint hint! :) )
  94. # [14:35] <Lachy> marcos, which spec?
  95. # [14:35] <marcos> Lachy: http://dev.w3.org/2006/waf/widgets/
  96. # [14:36] <Lachy> marcos, mail me the link to it and I'll take a look some time this week
  97. # [14:36] <Lachy> but also feel free to ping me daily until its done
  98. # [14:36] <marcos> Awesome! thanks Lachy.
  99. # [14:45] <marcos> fwiw, Artb, Danbri also raised similar issues at some point about having an extensibility point in the metadata. He even put together a proposal as to how GRRDL could be used.
  100. # [14:51] <ArtB> Marcos, are you still tweaking A&E spec?
  101. # [14:51] <marcos> nope
  102. # [14:51] <ArtB> ... in advance of FPWD, that is
  103. # [14:51] <ArtB> Arve, has the ball now?
  104. # [14:51] <marcos> yep
  105. # [14:54] <ArtB> Re "Objects implementing [HTML5]'s Window interface MUST also implement the WindowWidget interface. The WindowWidget interface provides access to [DOM3Core] Document objects in a widget context."
  106. # [14:54] <ArtB> ... should WindowWidget just be Widget?
  107. # [14:55] * Quits: arve (arve@213.236.208.22) (Client exited)
  108. # [14:55] <ArtB> oops; nevermind
  109. # [15:01] * Joins: arve (arve@213.236.208.22)
  110. # [15:06] <marcos> I'm worried about the issues you raised about the dependencies on specs. I'm not sure I understand the problem completely.
  111. # [15:06] <marcos> (above directed at Artb)
  112. # [15:06] <ArtB> A prob we may have is that P&C was at one time the 1 and only 1 spec
  113. # [15:07] <ArtB> It uses WUA (Widget User Agent) quite broadly
  114. # [15:07] <marcos> yeah
  115. # [15:07] <ArtB> P&C today is just about the manifest and package
  116. # [15:08] <ArtB> so if P&C normatively prescribes a WUA, that probably isn't correct
  117. # [15:09] <marcos> ok, I see what you mean
  118. # [15:09] <ArtB> I suspect cleaning up that terminology may be a bit painful
  119. # [15:09] <ArtB> so I don't think it must be done
  120. # [15:09] <ArtB> However, it will continue to create some confusion
  121. # [15:09] <marcos> it could be ok, but I'm still worried that a WUA is not defined (or it is defined, but just not explicitly).
  122. # [15:09] <ArtB> The P&C spec is NOT the right place to talk about a broad WUA, IMHO unless that "talk" is non-normative
  123. # [15:10] <marcos> ok, it should talk about a user agent that processes packages.
  124. # [15:10] <ArtB> bingo!
  125. # [15:10] <marcos> right. Ok. I'm with ya now.
  126. # [15:11] <marcos> This leads to the next issue
  127. # [15:11] <marcos> the problem of the dependency on the dig sig spec.
  128. # [15:12] <ArtB> I can see that DigSig will have a dependency on P&C e.g. for definitions
  129. # [15:13] <marcos> I don't see that dependency being different than the dependency on DOM3Core. We need DOM3Core, for instance, to give us TextNodes. As we need the Dig Sig spec to give us a status for the validity of a certificate.
  130. # [15:13] <ArtB> But you're saying it goes the other way?
  131. # [15:14] <marcos> We need to set a variable in the P&C spec based on how the user agent in the dig sig spec processes the signatures. The Dig Sig user agent's sole purpose is to provide that information to the packaging agent (or to other user agents as they may need to revalidate at runtime).
  132. # [15:15] <marcos> However, it could be the other way around
  133. # [15:16] <marcos> I.e., the widget dig sig spec could say something like "create variable X in the packaging specification and set it to be true". That seems wrong to me, however.
  134. # [15:18] * Quits: arve (arve@213.236.208.22) (Quit: Leaving)
  135. # [15:43] <marcos> Artb, I changed the packaging spec with regard to having a user agent that only operates on the package.
  136. # [15:46] <marcos> Responding to your email about this issue and outlining the changes
  137. # [15:51] <ArtB> Marcos, sigh on the DigSig dependency
  138. # [15:51] <marcos> I think we need it
  139. # [15:51] <marcos> But it's optional
  140. # [15:51] <ArtB> The change you made in the intro to Step #4 is the main thing I wanted
  141. # [15:51] <marcos> it was a totally valid point to make it optional.
  142. # [15:52] <ArtB> I'd love to say "and btw, if you support Wid-DigSig go there" and be done with it
  143. # [15:52] <ArtB> but maybe that's not possible ...
  144. # [15:53] <ArtB> Like you said, we need to hear from FH and MP and TLR and ...
  145. # [15:54] <ArtB> I think MP had a related point in http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0255.html
  146. # [15:57] <ArtB> It kinda' feels like we may not have the right work split re clear definition of the policy (e.g. what is valid), the policy decision point and the policy enforcement point
  147. # [15:59] <marcos> agreed
  148. # [16:20] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
  149. # [17:02] * Quits: gsnedders (gsnedders@86.136.52.180) (Quit: Killin' teh intarwebs)
  150. # [17:03] * Joins: gsnedders (gsnedders@86.136.52.180)
  151. # [17:20] * Joins: shepazu (schepers@128.30.52.30)
  152. # [17:35] * tlr is now known as tlr-bbl
  153. # [17:41] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  154. # [18:22] * Joins: Lachy (Lachlan@85.196.122.246)
  155. # [19:07] * Quits: gsnedders (gsnedders@86.136.52.180) (Quit: Killin' teh intarwebs)
  156. # [19:08] * Joins: gsnedders (gsnedders@86.136.52.180)
  157. # [20:31] * Quits: chaals (chaals@89.130.83.193) (Quit: chaals)
  158. # [20:35] <ArtB> shepazu, re DOM L3 Events spec, do you have a "delta doc" that describes the major changes/diff for L2?
  159. # [20:41] <shepazu> ArtB: no, I don't, but we shoudl make one
  160. # [20:41] * shepazu is at a conference right now
  161. # [20:50] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
  162. # [20:53] * tlr-bbl is now known as tlr
  163. # [21:07] * tlr is now known as tlr-off
  164. # [21:17] * Joins: chaals (chaals@89.130.83.193)
  165. # [21:34] * Quits: tlr-off (tlr@128.30.52.30) (Quit: tlr-off)
  166. # [21:47] * Joins: shepazu (schepers@128.30.52.30)
  167. # [22:28] * Quits: ArtB (ce846302@128.30.52.43) (Quit: CGI:IRC)
  168. # [22:45] * Quits: heycam (cam@124.168.33.158) (Quit: bye)
  169. # [23:06] * Joins: heycam (cam@130.194.72.84)
  170. # [23:18] <marcos> gsnedders: hehe :)
  171. # [23:23] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  172. # [23:37] * Joins: aroben (aroben@17.244.16.92)
  173. # [23:49] * Quits: aroben (aroben@17.244.16.92) (Ping timeout)
  174. # [23:54] * Joins: aroben (aroben@17.244.16.92)
  175. # Session Close: Tue Feb 03 00:00:00 2009

The end :)