/irc-logs / w3c / #webapps / 2015-02-25 / end

Options:

Previous day, Next day

  1. # Session Start: Wed Feb 25 00:00:00 2015
  2. # Session Ident: #webapps
  3. # [00:11] * Quits: sicking (~sicking@public.cloak) (sicking)
  4. # [00:12] * Joins: sicking (~sicking@public.cloak)
  5. # [00:29] * Quits: sicking (~sicking@public.cloak) (sicking)
  6. # [00:32] * Joins: sicking (~sicking@public.cloak)
  7. # [00:46] * Quits: smaug (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
  8. # [00:57] * Quits: sicking (~sicking@public.cloak) (sicking)
  9. # [01:01] * Joins: sicking (~sicking@public.cloak)
  10. # [01:07] * nickstenn is now known as zz_nickstenn
  11. # [02:04] * Quits: jsbell (~jsbell@public.cloak) ("There's no place like home...")
  12. # [02:17] * terri is now known as terri_offline
  13. # [02:18] * Quits: sicking (~sicking@public.cloak) (sicking)
  14. # [02:28] * heycam is now known as heycam|away
  15. # [02:41] * Quits: artb (~ArtB@public.cloak) ("Leaving.")
  16. # [03:48] * heycam|away is now known as heycam
  17. # [04:14] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
  18. # [04:46] * Quits: tantek (~tantek@public.cloak) (tantek)
  19. # [05:02] * Joins: marcosc (~marcosc@public.cloak)
  20. # [05:04] * Joins: tantek (~tantek@public.cloak)
  21. # [05:09] * Quits: tantek (~tantek@public.cloak) (tantek)
  22. # [05:38] * Joins: jyasskin (~textual@public.cloak)
  23. # [06:16] * heycam is now known as heycam|away
  24. # [06:25] * Joins: chaals (~Adium@public.cloak)
  25. # [06:32] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
  26. # [06:38] * heycam|away is now known as heycam
  27. # [06:49] * Joins: sicking (~sicking@public.cloak)
  28. # [06:57] * Joins: jyasskin (~textual@public.cloak)
  29. # [07:03] * Joins: tantek (~tantek@public.cloak)
  30. # [07:24] * Quits: sicking (~sicking@public.cloak) (sicking)
  31. # [07:40] * heycam is now known as heycam|away
  32. # [07:48] * Quits: tantek (~tantek@public.cloak) (tantek)
  33. # [07:49] * Joins: sicking (~sicking@public.cloak)
  34. # [08:08] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
  35. # [08:09] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
  36. # [08:26] * Joins: jmajnert (~quassel@public.cloak)
  37. # [08:36] * Joins: jyasskin (~textual@public.cloak)
  38. # [08:39] * Quits: sicking (~sicking@public.cloak) (sicking)
  39. # [09:09] * Joins: marcosc (~marcosc@public.cloak)
  40. # [09:16] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  41. # [10:38] * Joins: Lachy (~Lachy@public.cloak)
  42. # [10:40] * Joins: marcosc (~marcosc@public.cloak)
  43. # [11:46] * zz_nickstenn is now known as nickstenn
  44. # [11:48] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
  45. # [12:05] * Joins: chaals (~Adium@public.cloak)
  46. # [12:24] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
  47. # [12:42] * Joins: smaug (~chatzilla@public.cloak)
  48. # [12:45] * Quits: terri_offline (~terri@public.cloak) (Ping timeout: 180 seconds)
  49. # [13:01] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
  50. # [13:03] * Joins: chaals (~Adium@public.cloak)
  51. # [13:28] * Joins: jyasskin (~textual@public.cloak)
  52. # [13:40] * Quits: chaals (~Adium@public.cloak) (Client closed connection)
  53. # [13:41] * Joins: chaals (~Adium@public.cloak)
  54. # [13:43] * Joins: terri_offline (~terri@public.cloak)
  55. # [13:43] * terri_offline is now known as terri
  56. # [14:45] * Quits: smaug (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
  57. # [14:46] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
  58. # [14:53] * nickstenn is now known as zz_nickstenn
  59. # [15:04] * zz_nickstenn is now known as nickstenn
  60. # [15:40] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
  61. # [15:47] * Joins: marcosc (~marcosc@public.cloak)
  62. # [15:54] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  63. # [16:06] * Joins: dka (~dka@public.cloak)
  64. # [16:19] * Joins: smaug (~chatzilla@public.cloak)
  65. # [16:49] * Joins: fjh (~fhirsch3@public.cloak)
  66. # [16:55] * Quits: fjh (~fhirsch3@public.cloak) (fjh)
  67. # [16:57] * Joins: fjh (~fjh@public.cloak)
  68. # [16:58] * Joins: fjh_ (~fhirsch3@public.cloak)
  69. # [17:15] * Quits: fjh_ (~fhirsch3@public.cloak) (fjh_)
  70. # [17:32] * Quits: smaug (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
  71. # [17:36] * Joins: marcosc (~marcosc@public.cloak)
  72. # [17:42] * Joins: bkardell_ (~uid10373@public.cloak)
  73. # [17:43] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  74. # [17:55] * Joins: tantek (~tantek@public.cloak)
  75. # [18:01] * Quits: dka (~dka@public.cloak) (dka)
  76. # [18:25] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
  77. # [18:25] * Joins: chaals (~Adium@public.cloak)
  78. # [18:37] * Joins: fjh_ (~fhirsch3@public.cloak)
  79. # [18:57] * Joins: jsbell (~jsbell@public.cloak)
  80. # [19:00] * Quits: Lachy (~Lachy@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
  81. # [19:17] * Quits: fjh_ (~fhirsch3@public.cloak) (fjh_)
  82. # [19:24] * Joins: marcosc (~marcosc@public.cloak)
  83. # [19:32] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  84. # [19:49] * Quits: fjh (~fjh@public.cloak) (fjh)
  85. # [20:15] * Joins: fjh (~fhirsch3@public.cloak)
  86. # [20:17] * Quits: fjh (~fhirsch3@public.cloak) (fjh)
  87. # [20:18] * Joins: jyasskin (~textual@public.cloak)
  88. # [20:31] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
  89. # [20:35] * Joins: jyasskin (~textual@public.cloak)
  90. # [20:51] * Joins: sicking (~sicking@public.cloak)
  91. # [21:04] * Joins: marcosc (~marcosc@public.cloak)
  92. # [21:12] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  93. # [21:31] * nickstenn is now known as zz_nickstenn
  94. # [21:58] * Joins: shepazu (schepers@public.cloak)
  95. # [21:59] <shepazu> hey, I could use some WebIDL advice if anyone is around... I have an interface for an object, and one of the attributes takes a function... how do I express that in WebIDL (using Respec, if relevant)?
  96. # [22:00] <shepazu> would it be EventHandler ?
  97. # [22:01] <shepazu> or maybe it should be handled as a callback...?
  98. # [22:05] * Joins: marcosc (~marcosc@public.cloak)
  99. # [22:06] <jsbell> shepazu: EventHandler is just a particular signature of callback: https://html.spec.whatwg.org/multipage/webappapis.html#eventhandler
  100. # [22:07] <shepazu> jsbell, so what would you do for this? http://w3c.github.io/web-annotation/api/rangefinder/#widl-RangeFinder-customSelector
  101. # [22:10] <jsbell> callback CustomSelectorCallback = any (DOMString documentString); interface RangeFinder { ... attribute CustomSelectorCallback customSelector; ... }
  102. # [22:11] <jsbell> ideally replacing "any" with something more specific, but I don't have enough context
  103. # [22:11] <shepazu> jsbell, interesting
  104. # [22:12] <shepazu> jsbell, what does "any" mean here?
  105. # [22:13] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
  106. # [22:13] * Joins: elijah (~sid21431@public.cloak)
  107. # [22:13] <jsbell> http://heycam.github.io/webidl/#idl-any - the function can return anything, no type conversion is specified by the IDL
  108. # [22:14] <jsbell> http://heycam.github.io/webidl/#idl-callback-functions
  109. # [22:18] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
  110. # [22:18] <shepazu> oh, ok... so it could return a Promise, or a RangeFinderResult? http://w3c.github.io/web-annotation/api/rangefinder/#idl-def-RangeFinderResult
  111. # [22:19] <shepazu> thanks, jsbell!
  112. # [22:19] <shepazu> jsbell, have we met IRL, maybe at TPAC?
  113. # [22:20] <jsbell> probably, I'm bad with names. :)
  114. # [22:21] <jsbell> shepazu: Yeah. But if you know that specifically, you could replace any with (RangeFinderResult or Promise<RangeFinderResult>)
  115. # [22:22] <shepazu> jsbell, ok, I was just reading that... my understanding of Promises is... terrible
  116. # [22:23] <jsbell> Unions of (T or Promise<T>) are bad for system-supplied operations (since user code has to probe...) but since this is a user function it might be okay...
  117. # [22:23] <shepazu> I understood all of those words individually :)
  118. # [22:24] * Joins: jyasskin (~textual@public.cloak)
  119. # [22:24] * chaals looks skeptical
  120. # [22:25] <jsbell> shepazu: an API like: document.getFoo() that returned a Foo or a Promise<Foo> would be a pain to use, since you'd always need to probe the result or always cast to a Promise, e.g. Promise.resolve(document.getFoo()).then(...) anyway
  121. # [22:27] <shepazu> jsbell, the constraint I'm trying to address is that text-search operations can be somewhat resource-intensive, and I thought maybe a Promise might be a better way to address that...
  122. # [22:27] <shepazu> but then again, I might simply be talking nonsense
  123. # [22:27] * shepazu waits for chaals...
  124. # [22:28] <jsbell> You're right. The question is, should the script's function be forced to be synchronous if it's not intensive.
  125. # [22:28] <jsbell> er, forced to be *A*synchronous if it's not intensive
  126. # [22:28] <shepazu> jsbell, yeah, that's the dilemma!
  127. # [22:29] <shepazu> I want it to be easy to use and intuitive, but need to consider the hard cases
  128. # [22:30] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
  129. # [22:32] <jsbell> So, in Service Worker, we have methods like; respondWith(Response or Promise<Response>). This isn't really different; spec-wise, whatever the function returns is wrapped with Promise.resolve(x) which is a no-op if it's already a Promise. (That implies that further process is always asynchronous even if the function returns a non-promise, though, which you probably want anyway for consistency.)
  130. # [22:35] <shepazu> how far along is ServiceWorker?
  131. # [22:37] <jsbell> shepazu: large chunks of the API are already shipping in Chrome (stable), more coming in each release. Moz's implementation is fairly far along, dunno what their release plans are. So spec is proven implementable. :) Lots of ongoing refinement, though.
  132. # [22:38] <shepazu> I wonder if it would work for RangeFinder's timeline... we don't have any implementations yet, or even any commitments, so maybe so
  133. # [22:40] <jsbell> shepazu: I'm not sure I see the relationship between RF and SW...?
  134. # [22:42] <shepazu> jsbell, maybe I'm conflating ServiceWorker and worker threads?
  135. # [22:42] <shepazu> I thought I might take a fire-and-forget approach with RangeFinder
  136. # [22:42] * heycam|away is now known as heycam
  137. # [22:43] <shepazu> but I'm probably hopelessly lost at the moment, need more sleep
  138. # [22:43] <shepazu> heycam, speak of the devil!
  139. # [22:43] <shepazu> heycam, got time for some RangeFinder advice?
  140. # [22:44] <shepazu> heycam, specifically, what should I do here? http://w3c.github.io/web-annotation/api/rangefinder/#widl-RangeFinder-customSelector
  141. # [22:44] * heycam looks
  142. # [22:44] * Joins: marcosc (~marcosc@public.cloak)
  143. # [22:45] <heycam> shepazu, what's the question?
  144. # [22:47] <shepazu> heycam, the attribute takes a function, which right now is defined as a DOMString, which is obviously hideously wrong
  145. # [22:48] <heycam> shepazu, ah yes :)
  146. # [22:48] <shepazu> jsbell suggested this:
  147. # [22:48] <heycam> shepazu, you need to define an IDL callback, which is essentially a function
  148. # [22:48] <shepazu> callback CustomSelectorCallback = Promise<RangeFinderResult> (DOMString documentString); interface RangeFinder { ... attribute CustomSelectorCallback customSelector; ... }
  149. # [22:48] <heycam> yes that should work
  150. # [22:49] <shepazu> and then we discussed how Promises are tricky, and how I don't actually understand them
  151. # [22:49] <heycam> ha :)
  152. # [22:50] <jsbell> callback CustomSelectorCallback = (RangeFinderResult or Promise<RangeFinderResult>) (DOMString documentString); - is that too weird?
  153. # [22:50] <heycam> I think that would be awkward for authors to use
  154. # [22:50] <shepazu> he said many smart thinks I wish I understood
  155. # [22:50] <heycam> you'd need to test whether the thing returned was a promise or not
  156. # [22:50] <shepazu> that's what he was saying...
  157. # [22:50] <heycam> oh this is for the script author to return something to the RangeFinder, I forgot
  158. # [22:51] <shepazu> yes
  159. # [22:51] <heycam> I don't think it makes sense to return a promise here if the rest of your API is sync
  160. # [22:51] <heycam> e.g. search()
  161. # [22:51] <shepazu> and I was wondering if maybe search() should be a promise
  162. # [22:51] <heycam> right :)
  163. # [22:52] <shepazu> which, again, ugly for devs
  164. # [22:52] <heycam> uglier would be to make it promise-or-not-promise
  165. # [22:52] <shepazu> but maybe necessary, given the possible resource-hoggery of searches
  166. # [22:52] <heycam> do you expect the customSelector functions to take a long time to run?
  167. # [22:52] <shepazu> maybe always promise?
  168. # [22:53] <shepazu> heycam, hard to say
  169. # [22:53] <shepazu> but for long docs... maybe so
  170. # [22:54] <shepazu> I honestly don't know if RF should be sync or async
  171. # [22:54] <heycam> I'm not sure either
  172. # [22:55] <heycam> the documentString that gets passed in
  173. # [22:56] <heycam> is that the whole document's text?
  174. # [22:56] <shepazu> heycam, I pay you to know these things!
  175. # [22:56] <shepazu> heycam, which documentString, the one in the callback? yes
  176. # [22:56] <heycam> and is it short each time you call search() (so the tail of the document, after the current match)?
  177. # [22:56] <heycam> yes
  178. # [22:56] <heycam> *shorter
  179. # [22:57] <shepazu> well, yes, if .wrap=false
  180. # [22:57] <heycam> how does the customSelector indicate that there are no more matches?
  181. # [22:57] <heycam> (well, how does search()?)
  182. # [22:58] <shepazu> if search() doesn't find anything, it returns null for the range
  183. # [22:58] <shepazu> and 0 for confidence
  184. # [22:58] <shepazu> whether that's the last search, or simply an unsuccessful one
  185. # [22:59] <shepazu> if .wrap=true, then you can keep a list of results, and compare with the first search result
  186. # [22:59] <heycam> if you want to return null, you should make the type |RangeFinderResult?|
  187. # [22:59] <shepazu> dunno if that's the best way, but it's what I started with
  188. # [22:59] <heycam> oh for the Range object inside
  189. # [22:59] <heycam> ok
  190. # [22:59] <heycam> either way
  191. # [22:59] <shepazu> ah, right
  192. # [22:59] <heycam> then |Range?| for the dictionary member type
  193. # [23:00] <shepazu> right
  194. # [23:00] <heycam> anyway, I don't have a good answer about promises or not
  195. # [23:00] <heycam> but the callback syntax jsbell mentions is right
  196. # [23:02] <shepazu> ok
  197. # [23:02] <shepazu> thanks, heycam and jsbell!
  198. # [23:02] <shepazu> oh, heycam
  199. # [23:03] <shepazu> you see how ugly my API + ArgsWebIDL is?
  200. # [23:03] <heycam> oh, the duplication?
  201. # [23:03] <heycam> yeah there's no good away around that
  202. # [23:03] <shepazu> I'm using Respec... not sure if I can make it point to the object definitions
  203. # [23:04] <shepazu> heycam, is that a problem with respec, with webidl, or am I just doing it wrong?
  204. # [23:04] <heycam> the fact that you have a bunch of dictionary members, then the same things but as attributes in the interface?
  205. # [23:04] <shepazu> yes
  206. # [23:04] <heycam> that is just a limitation of webidl
  207. # [23:04] <shepazu> webidl sucks, then :)
  208. # [23:04] <heycam> you can't say "insert dictionary members here for all attributes on this interface" for example
  209. # [23:05] <shepazu> well, so long as I'm not doing it wrong, I guess I'm okay
  210. # [23:05] <heycam> could make something up for that
  211. # [23:05] <heycam> not sure how clear it would be to read, though
  212. # [23:05] <shepazu> heycam, did I make a mistake folding the dictionaries into the interface? should I have kept them separate?
  213. # [23:05] <heycam> shepazu, not sure what you mean?
  214. # [23:06] <heycam> by folding in
  215. # [23:06] <shepazu> and should I define them before or after the interface itself?
  216. # [23:06] <jsbell> you mean one big webidl block in the spec or many?
  217. # [23:06] <shepazu> jsbell, correct
  218. # [23:07] <shepazu> I used the data-merge="RangeFinderResult RangeFinderArgs RangeFinderState" feature of Respec
  219. # [23:07] <heycam> I think it's fine in one block
  220. # [23:07] <shepazu> on the interface definition
  221. # [23:07] <shepazu> ok
  222. # [23:07] <heycam> the section that describes the dictionary members
  223. # [23:07] <heycam> seems unnecessary though :)
  224. # [23:08] <heycam> or you could replace it with a single sentence saying that each one has the same meaning as the corresponding attribute on the interface
  225. # [23:08] <heycam> or something like that
  226. # [23:08] <shepazu> heycam, hey, that's what Respec outputs
  227. # [23:08] <shepazu> heycam, I'd prefer that, but I don't think Respec can do it
  228. # [23:08] <shepazu> or, I haven't figured out how
  229. # [23:08] <shepazu> I think I'll try to move it to the end
  230. # [23:11] * Quits: tantek (~tantek@public.cloak) (tantek)
  231. # [23:11] <shepazu> this was useful guys, thanks!
  232. # [23:12] <heycam> np
  233. # [23:26] * Quits: bkardell_ (~uid10373@public.cloak) ("Connection closed for inactivity")
  234. # Session Close: Thu Feb 26 00:00:00 2015

Previous day, Next day

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn