/irc-logs / freenode / #whatwg / 2008-11-20 / end

Options:

  1. # Session Start: Thu Nov 20 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [09:12] * Attempting to rejoin channel #whatwg
  4. # [09:12] * Rejoined channel #whatwg
  5. # [09:12] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  6. # [09:12] * Set by Hixie on Thu Oct 23 14:38:15
  7. # [09:23] * Disconnected
  8. # [09:23] * Attempting to rejoin channel #whatwg
  9. # [09:23] * Rejoined channel #whatwg
  10. # [09:23] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  11. # [09:23] * Set by Hixie on Thu Oct 23 14:38:15
  12. # [09:27] <hsivonen> hmm. Perhaps Roy hasn't looked at what some of the 2000 Apache committers have been up to lately...
  13. # [10:00] * Disconnected
  14. # [10:00] * Attempting to rejoin channel #whatwg
  15. # [10:00] * Rejoined channel #whatwg
  16. # [10:00] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  17. # [10:00] * Set by Hixie on Thu Oct 23 14:38:15
  18. # [11:31] * Disconnected
  19. # [11:31] * Attempting to rejoin channel #whatwg
  20. # [11:31] * Rejoined channel #whatwg
  21. # [11:31] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  22. # [11:31] * Set by Hixie on Thu Oct 23 14:38:15
  23. # [11:31] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
  24. # [11:32] <Hixie> danbri: (i ask merely because different people have said similar things but in each case meant something different)
  25. # [12:10] * Disconnected
  26. # [12:10] * Attempting to rejoin channel #whatwg
  27. # [12:10] * Rejoined channel #whatwg
  28. # [12:10] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  29. # [12:10] * Set by Hixie on Thu Oct 23 14:38:15
  30. # [12:10] <danbri> and dropped in html5?
  31. # [12:10] <Hixie> nope
  32. # [12:56] * Disconnected
  33. # [12:56] * Attempting to rejoin channel #whatwg
  34. # [12:56] * Rejoined channel #whatwg
  35. # [12:56] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  36. # [12:56] * Set by Hixie on Thu Oct 23 14:38:15
  37. # [12:56] <mookid> I'm not saying you dont understand I'm saying you can't tell
  38. # [12:56] <Hixie> so how could i get the perspective to tell?
  39. # [12:56] <mookid> by allowing both
  40. # [12:56] <mookid> and seeing what happens
  41. # [12:56] <mookid> why do you even want to make that call
  42. # [12:56] <Hixie> we can't both allow and disallow content negotiation
  43. # [12:57] <mookid> if someone makes a web app with HTTP conneg
  44. # [12:57] <mookid> and it's crap for users..
  45. # [12:57] <Hixie> they're mutually exclusive options
  46. # [12:57] <mookid> gues what
  47. # [12:57] <mookid> NO ONE WILL USE IT
  48. # [12:57] <mookid> that's how capitalism works
  49. # [12:57] <Hixie> right, indeed, nobody uses it
  50. # [12:57] <mookid> NO
  51. # [12:57] <Hixie> we've seen that already
  52. # [12:57] <mookid> that's wrong
  53. # [12:57] <Hixie> well, a few people do
  54. # [12:57] <gsnedders> hsivonen: I was discussing it with him in private, but the current draft hal CC: www-tag
  55. # [12:57] <mookid> nobody uses it because it's not provisioed for by existing technmologies
  56. # [12:57] <Hixie> w3c does for some resources
  57. # [12:57] <mookid> that's circular argument
  58. # [12:57] <mookid> and you know it
  59. # [12:57] <Hixie> though almost uniformly when they do, they screw things up
  60. # [12:57] <mookid> it's totally disingeous
  61. # [12:57] <hsivonen> "progression of a technologist" reminds me of TUITT (The Architect's Progress) :-)
  62. # [12:57] <mookid> no
  63. # [12:57] <mookid> go back
  64. # [12:57] <hsivonen> gsnedders: ah
  65. # [12:57] <mookid> just go back
  66. # [12:57] <gsnedders> *has
  67. # [12:57] <mookid> < Hixie> right, indeed, nobody uses it
  68. # [12:57] <mookid> < Hixie> right, indeed, nobody uses it
  69. # [12:58] <mookid> taht is nonsense
  70. # [12:58] <mookid> nobody has th oppotunity to use it
  71. # [12:58] <mookid> because you cant do it
  72. # [12:58] * Joins: famicom_ (i=famicom@5ED2FF2D.cable.ziggo.nl)
  73. # [12:58] <mookid> there's no reason you can't provision for both HTTP and URI conneg
  74. # [12:58] <Hixie> how so? all the browsers support it, all the servers support it, why would people not use it if they wanted it?
  75. # [12:58] <mookid> they arent mututally exclusive
  76. # [12:58] <mookid> the browsers dont support it
  77. # [12:58] <Hixie> sure they do
  78. # [12:58] <mookid> no they dont
  79. # [12:58] <Hixie> they send Accept headers correctly
  80. # [12:59] * Quits: famicom_ (i=famicom@5ED2FF2D.cable.ziggo.nl) (Client Quit)
  81. # [12:59] <mookid> not dynamically there's no markup for it
  82. # [12:59] <mookid> that's my point.
  83. # [12:59] <Hixie> the markup idea doesn't do content _negotiation_, it does content _selection_, which is what URIs are _for_
  84. # [12:59] <Hixie> URIs are resource identifiers
  85. # [12:59] <mookid> URIs are USED THAT WAY AT THE MOMENT
  86. # [12:59] <mookid> BECAUSE OF THAT
  87. # [13:00] <mookid> you're looking at the relationship wrong
  88. # [13:00] <Hixie> right, that's the architecture of the web
  89. # [13:00] <mookid> the reason
  90. # [13:00] <mookid> URIs are used to do that
  91. # [13:00] <mookid> is because there's no other alternative
  92. # [13:00] <mookid> it's NOT PROVISIONED FOR
  93. # [13:00] <Hixie> why do we need an alternative?
  94. # [13:00] <mookid> why not?
  95. # [13:00] <mookid> it's another pattern
  96. # [13:00] <gsnedders> Bloat?
  97. # [13:00] <Hixie> because we don't need it
  98. # [13:00] <hsivonen> alternatives are expensive
  99. # [13:00] <Hixie> and it's expensive to implement, spec, test, and debug
  100. # [13:00] <mookid> if you can provision for it simply and withotu breaking existing methodologies
  101. # [13:00] <mookid> why would you not do that
  102. # [13:00] <mookid> the answer is that
  103. # [13:00] <mookid> you dont agree with that way of doing thigns
  104. # [13:00] <Hixie> surely we should be focusing on making sure we fit the web's architecture, anyway
  105. # [13:00] <gsnedders> Unless we need something, it just bloats the spec and makes implementing it more expensive
  106. # [13:01] <mookid> well you should'nt have the authority to do that
  107. # [13:01] <Hixie> which is that uris are identifiers for resources
  108. # [13:01] <mookid> what is a resource?
  109. # [13:01] <hsivonen> mookid: should you have the authority?
  110. # [13:01] <mookid> I have my definition
  111. # [13:01] <mookid> you have you
  112. # [13:01] <mookid> yorus
  113. # [13:01] <mookid> I'm saying
  114. # [13:01] <mookid> lets both do it our ways
  115. # [13:01] <mookid> and see which one wins
  116. # [13:01] <mookid> your saying
  117. # [13:01] <Hixie> "you're"
  118. # [13:01] <mookid> dont be a dick
  119. # [13:02] <Hixie> every time you misuse "your" i get really confused
  120. # [13:02] <mookid> seriously?
  121. # [13:02] <mookid> wow.
  122. # [13:02] <jgraham> mookid: AFAICT in your "arcitecture" you would still need to have unique URIs for unique content types so that you could do something like a HTML page with links to specific versions of the resource, which you have said would be the fallback for browsers that didn't support <a accept>
  123. # [13:02] <Hixie> yeah i'm like "my saying? what saying? what?"
  124. # [13:02] <jgraham> architecture*
  125. # [13:02] <mookid> it's funny why you've stopped the conversation
  126. # [13:02] <mookid> is taht becaue you're in a hole
  127. # [13:03] <mookid> perhaps?
  128. # [13:03] <Hixie> i'm still confused about how this accept attribute would work when you want to copy and paste the url
  129. # [13:03] <mookid> ABORT ABORT
  130. # [13:03] <mookid> it doesnt work - it depends on the default accept headers of the client
  131. # [13:03] <Hixie> but more importantly, we've explained that new features are expensive, and that we don't see an advantage to this proposal, as it doesn't introduce anything
  132. # [13:03] <Hixie> and we've explained how it breaks the web's architecture
  133. # [13:03] <mookid> that's how I want my application to behave..
  134. # [13:03] <mookid> yhou dont
  135. # [13:03] <mookid> that's fine
  136. # [13:03] <mookid> why cant we both have our way?
  137. # [13:03] <wilhelm> Even if this suggestion makes it into the spec, you would still have to convince browser vendors to actually implement it.
  138. # [13:03] <mookid> why do you have to restrict me
  139. # [13:03] <mookid> on the basis that you think you're right
  140. # [13:04] <mookid> well at least I have one step done
  141. # [13:04] <mookid> then I can do the next
  142. # [13:04] <Hixie> are you going to pay the engineers to implement this, to test it, to spec it, to write the tutorials, to debug their apps when it breaks, etc?
  143. # [13:04] <hsivonen> mookid: should we have as many ways of doing things as there are people in the world?
  144. # [13:04] <mookid> hsivonen: no, clearly not shut up
  145. # [13:04] <jgraham> mookid: be civil
  146. # [13:04] <mookid> no he's being annoying
  147. # [13:05] <Hixie> so are you but we're still being polite :-)
  148. # [13:05] <mookid> passive agressive is agressive
  149. # [13:05] <mookid> I just dont act like agirl
  150. # [13:05] <mookid> :)
  151. # [13:05] <Hixie> his point is well made, though, if five people want five different things, we obviously don't want to add five features to the language
  152. # [13:05] <mookid> Hixie: I dont have to pay anyone - developers that believed in doing it that way would od it
  153. # [13:05] <Hixie> we have to pick the right nes
  154. # [13:05] <mookid> the ones that didnt
  155. # [13:05] <mookid> wouldnt
  156. # [13:05] <mookid> funnily enough
  157. # [13:05] <mookid> but btoh can co-exist
  158. # [13:06] <mookid> there's not imcopatability
  159. # [13:06] <Hixie> mookid: ok, well, i am deciding not to do it
  160. # [13:06] <mookid> WHY?
  161. # [13:06] <Hixie> mookid: because you won't pay me to add it to the spec :-)
  162. # [13:06] <mookid> erm
  163. # [13:06] <Hixie> mookid: it costs me time to do it
  164. # [13:06] <mookid> aaaahhhhhhh
  165. # [13:06] <Hixie> mookid: and you aren't willing to pay the cost
  166. # [13:06] <mookid> here we are
  167. # [13:06] <mookid> why didnt you just say that?
  168. # [13:06] <Hixie> i did
  169. # [13:06] <mookid> no you didnt
  170. # [13:06] <Hixie> i said adding teh feature was expensive
  171. # [13:06] <mookid> that's the first time you've mentioned money
  172. # [13:06] <mookid> how much does it cost?
  173. # [13:07] <krijnh> -_-
  174. # [13:07] <mookid> If I buy you a boko on web architecture will you do it?
  175. # [13:07] <hsivonen> do we have a link to an explanation of opportunity cost from the FAQ yet?
  176. # [13:07] <mookid> I nkow what an opporunity cost is
  177. # [13:07] <mookid> cost forgone by chosing the next best alternative
  178. # [13:08] <Hixie> well there's the 15 minutes for me to write the spec, the day or two spent fixing the spec over the next few months, the month or so of writing test cases, then the browser vendors each have to implement it so that's a dozen times a few days, then there's the tutorial writers who will have to spend a few hours or days explaining it
  179. # [13:08] <mookid> just for one optional attribute?
  180. # [13:08] <Hixie> then there's the cost of all the people who try to understand it, probably 5 minutes to an hour each, times maybe 100 million people
  181. # [13:08] <wilhelm> Implementation, testing, debugging, regression testing on every nightly build with all used configurations-- even the smallest features takes a lot of resources.
  182. # [13:08] <mookid> wow your processes are SERIOUSLY broken
  183. # [13:08] <Hixie> then there's the cost of regression testing that wilhelm mentions
  184. # [13:09] <mookid> I can't honestly believe that one optional attribute can make that much difference in the grand scheme of things
  185. # [13:09] <Hixie> then there's the cost of actual debugging for people using this
  186. # [13:09] * Quits: roc (n=roc@121-72-209-122.dsl.telstraclear.net)
  187. # [13:09] <Hixie> let's assume an hour or so for a million people...
  188. # [13:09] <mookid> thos arent costs to this project that's not a reasonable argument
  189. # [13:10] <krijnh> (Don't forget the hours spent on this in IRC :)
  190. # [13:10] <mookid> those will be incurred by the 'insane' people who want to use HTTP conneg
  191. # [13:10] * Joins: famicom_ (i=famicom@5ED2FF2D.cable.ziggo.nl)
  192. # [13:10] * jgraham will be expecting his cheque in the post :)
  193. # [13:10] <mookid> I meant.. what does it cost to get this in the spec
  194. # [13:10] <mookid> not - what are the projected costs to industry
  195. # [13:10] <mookid> if it's not worth it
  196. # [13:11] <mookid> indstry wont pay for it
  197. # [13:11] <Hixie> so let's see... assuming $20/hour, that would be... about a billion dollars total, if my calculations are correct.
  198. # [13:11] <mookid> for one attribute?
  199. # [13:11] <Hixie> yup
  200. # [13:11] <mookid> you're a joke.
  201. # [13:11] <Hixie> that's why we only add the minimum
  202. # [13:11] <Hixie> well the cost is spread over the entire human race
  203. # [13:11] <mookid> ilke VIDEOTAGS
  204. # [13:11] <Hixie> over many decades
  205. # [13:11] <mookid> we already have video tags
  206. # [13:11] <mookid> we can already embed sounds
  207. # [13:11] <Hixie> consider how much money google paid to buy youtube
  208. # [13:11] <mookid> why not just fix the tags that exist?
  209. # [13:11] <mookid> rather than creat your own gay new markup
  210. # [13:11] <Hixie> and then you'll see that a billion dollars for a feature like that doesn't sound like much anymore
  211. # [13:12] <mookid> that no user actually cares about
  212. # [13:12] <mookid> who reads html
  213. # [13:12] <mookid> seriously
  214. # [13:12] <Hixie> because that feature makes money :-)
  215. # [13:12] <mookid> no ti doesnt
  216. # [13:12] <mookid> video on teh web makes money
  217. # [13:12] <mookid> you can do that with the tags that exist
  218. # [13:12] <Hixie> right
  219. # [13:12] <mookid> they need fixing
  220. # [13:12] <Hixie> not without paying adobe
  221. # [13:13] <wilhelm> Porting Flash to new platforms along with a browser is a pain.
  222. # [13:13] <mookid> so it would cost whatwg how much to add this attribute?
  223. # [13:13] <wilhelm> I'd prefer not to do that again. (c:
  224. # [13:13] <Hixie> it would cost hte whatwg nothing at all, the whatwg has no money. it would cost the human race about a billion dollars spread over a few years.
  225. # [13:13] <mookid> investment
  226. # [13:13] <Hixie> with what return?
  227. # [13:13] <mookid> who knows
  228. # [13:14] <mookid> they arent going to pay up if there's no ROI
  229. # [13:14] <Hixie> exactly
  230. # [13:14] <mookid> why dont you let them decide that
  231. # [13:14] <mookid> WHY DONT
  232. # [13:14] <mookid> YOU LET
  233. # [13:14] <mookid> THEM DECIDE
  234. # [13:14] <Hixie> because i am paid to make these judgement calls
  235. # [13:14] <mookid> how difficult is it to understand that is the most efficient way to make that descision
  236. # [13:14] <Hixie> that's my job
  237. # [13:14] <mookid> it's how our economies work
  238. # [13:14] <Hixie> well
  239. # [13:14] <Hixie> yes
  240. # [13:14] <annevk2> who is "them"?
  241. # [13:14] <krijnh> Wb annevk2 :)
  242. # [13:14] <Hixie> sometimes, the browser vendors implement things without a spec
  243. # [13:14] <mookid> do you know Smith's "invisible hand" ?
  244. # [13:14] <annevk2> thx krijnh
  245. # [13:14] <hsivonen> wilhelm: did Opera port Flash to Wii?
  246. # [13:15] <Hixie> and that's when i know i made a mistake in saying "no"
  247. # [13:15] <mookid> erm
  248. # [13:15] <Hixie> and sometimes, the browser vendors don't implement something that i put in the spec
  249. # [13:15] <mookid> lol
  250. # [13:15] <Hixie> and that's when i know i made a mistake in saying "yes"
  251. # [13:15] <mookid> by not putting it in the spec you create an articificial barrier to entry
  252. # [13:15] <Hixie> but in this particular case, i haven't heard a single browser vendor be positive about it
  253. # [13:15] <wilhelm> hsivonen: Yes.
  254. # [13:16] <mookid> it's something else they have to worry about 0 they probably dont understand it
  255. # [13:16] <mookid> so you've talked to browser vendors about this?
  256. # [13:16] <mookid> that's blatantly a lie
  257. # [13:16] * Quits: famicom (i=famicom@5ED2FF2D.cable.ziggo.nl) (Read error: 110 (Connection timed out))
  258. # [13:17] <Philip`> Hixie: C's pointer syntax made more sense when I learned that the type declarations were meant to reflect how you would use variables of that type, e.g. "char **foo" means *foo is a char* and **foo is a char, and "char *foo[]" means foo[n] is a char* and *foo[n] is a char
  259. # [13:17] <jgraham> mookid: You've tlked to browser vendors
  260. # [13:17] <wilhelm> mookid: You are talking to browser vendors about this right now.
  261. # [13:17] <Hixie> mookid: pretty much everyone who has spoken in this conversation other than me and you is a browser vendor
  262. # [13:17] <mookid> ahh taht explains ALOT
  263. # [13:17] <mookid> :)
  264. # [13:17] <Hixie> actually i guess now that the G1 is out and Chrome is out even i'm technically a browser vendor
  265. # [13:18] <hsivonen> Philip`: putting * after the space has never made sense to me. I always think that pointerness is part of the type.
  266. # [13:18] <Hixie> but we'll gloss over that so i can continue to act as a vendor-neutral arbitor!
  267. # [13:18] <mookid> huhuhuhu
  268. # [13:18] <tthorsen> hsivonen: consider this "char* a, b" a is a pointer to a char, but b is just a char
  269. # [13:18] <Hixie> hsivonen: it only makes sense because of the binding of the star token in "int* a, b" (b's type is "in" not "int*")
  270. # [13:18] <Hixie> what tthorsen said
  271. # [13:19] <Philip`> hsivonen: It seems to make some sense either way - "char* x" means x is a char*, while "char *x" means *x is a char
  272. # [13:19] <Hixie> but that's a bug in C and i agree that the * should be before the space
  273. # [13:19] <hsivonen> tthorsen: I don't declare multiple variables on one line in C or C++.
  274. # [13:19] <mookid> no offence but how many 'big thinkers' are invovled in the nitty gritty of HTML5 -_-
  275. # [13:19] <mookid> brwoser vendors or not
  276. # [13:19] <Hixie> mookid: how does one determine if one is a big thinker?
  277. # [13:19] <mookid> I just really dont think this is the appropriate place to be making design descisions
  278. # [13:20] <Hixie> where is appropriate?
  279. # [13:20] <mookid> well..
  280. # [13:20] <mookid> DESIGN TIME?
  281. # [13:20] <mookid> maybe?
  282. # [13:20] <mookid> ...
  283. # [13:20] <Hixie> in #whatwg it is design time all the time
  284. # [13:20] <Hixie> that's what we do
  285. # [13:20] <mookid> you dont do application design
  286. # [13:20] <jgraham> Apart from when we are discussing gsnedders poetry.
  287. # [13:21] <mookid> specifically web application design
  288. # [13:21] <jgraham> That is not spec design :)
  289. # [13:21] <Hixie> oh i thought you mean the design of the language
  290. # [13:21] <Hixie> i don't think it would make much sense to decide what tags html had when writing a web app :-)
  291. # [13:21] <Hixie> it's kinda late by then
  292. # [13:21] <mookid> It's notyruo place to start rejecting features on the basis that you need to 'protect' users from 'crazy' architects/developers
  293. # [13:21] <mookid> what?
  294. # [13:21] <mookid> Hixie:
  295. # [13:22] <mookid> developers are entirely restricted by thtat
  296. # [13:22] <Hixie> should we just add all features that people request then?
  297. # [13:22] <mookid> no just the ones that don't break anything else and provide more alternatives to developers
  298. # [13:22] <mookid> users dont care about html
  299. # [13:22] <mookid> developers do
  300. # [13:23] <Hixie> your proposal breaks the web architecture
  301. # [13:23] <mookid> no it doesnt
  302. # [13:23] <mookid> you can still write URI based conneg with my proposal
  303. # [13:23] <Hixie> the web architecture is that a resource is identified by a uri
  304. # [13:23] <mookid> you can still do it your way
  305. # [13:23] <Hixie> you are proposing making them identify multiple resources
  306. # [13:23] <mookid> even if my proposal is implemetned
  307. # [13:23] <mookid> my proposal is to provide the OPTION
  308. # [13:23] <Hixie> the option to break the web architecture, right
  309. # [13:23] <mookid> that's compltely different
  310. # [13:23] <mookid> no
  311. # [13:23] <mookid> not to break it
  312. # [13:24] <mookid> the old design
  313. # [13:24] <mookid> and OLD applications
  314. # [13:24] <mookid> will still work
  315. # [13:24] <mookid> there's no change there..
  316. # [13:24] <mookid> it's only developers who make web apps that serve html with the attribute
  317. # [13:24] <mookid> that will have any change
  318. # [13:24] <Hixie> so we should add all features that people ask for if those features are optional?
  319. # [13:24] <mookid> provided they dont break anything else
  320. # [13:24] <mookid> and they have a valid use for them
  321. # [13:25] <mookid> which I'v eclrealy demonstrated
  322. # [13:25] <Hixie> wow, that would make for one hell of a big and confusing language
  323. # [13:25] <mookid> not really
  324. # [13:25] <mookid> if you use your brain
  325. # [13:25] <Hixie> dude i have literally THOUSANDS of e-mails of feature requests
  326. # [13:25] <Hixie> to go through
  327. # [13:25] <mookid> oh right ok then
  328. # [13:25] <Hixie> most of which are optional
  329. # [13:25] <mookid> maybve think abuot letting someone else help?
  330. # [13:25] <Hixie> it's not a matter of it taking time
  331. # [13:25] <mookid> or do you not feel like sharing the glory?
  332. # [13:25] <Hixie> it's a matter of the size of the language if we added them all!
  333. # [13:26] <mookid> or trust anyone to be as super intelligent as you obviously are
  334. # [13:26] <mookid> protector of the web
  335. # [13:26] <mookid> (architecturE)
  336. # [13:26] <mookid> it's a nonsense position to take
  337. # [13:26] <Hixie> (actually i've already requested volunteers to take over certain parts of the spec)
  338. # [13:26] <Hixie> (btu that's independent of my point here)
  339. # [13:26] <Hixie> but
  340. # [13:26] <mookid> I'll happilly work on that part and anything else you need
  341. # [13:26] <Hixie> sweet
  342. # [13:27] <mookid> it's a shame there's no web site for proposals though
  343. # [13:27] <Philip`> Specs are useless unless they're implemented, and implementors have limited resources, so even if we had infinite spec-editing capability we'd have to limit the size of the language
  344. # [13:27] <Hixie> http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html has the details of what needs doing
  345. # [13:28] <Hixie> right, the original point still stands, which is that we'd be irresponsible to just accept all (optional) proposals
  346. # [13:28] <mookid> right it's a trade off.. but it's pretty obvious that HTTP centric apps are emerging as a a new approach
  347. # [13:28] <mookid> otherwise why would you be implementing PUT/DELETE?
  348. # [13:29] <Hixie> ok if you agree that it is a tradeoff... what is it a tradeoff between?
  349. # [13:29] <mookid> between what it adds.. adding the functionality from HTTP conneg is a big addition with minimal cost and complete backwards compatability
  350. # [13:30] <mookid> the fact that you wouldn't use it
  351. # [13:30] <mookid> is neither here nor there
  352. # [13:30] <mookid> frankly
  353. # [13:30] <mookid> I mean
  354. # [13:30] <mookid> what realistically does a video tag add?
  355. # [13:30] <Hixie> well in the case of your proposal, it adds nothing, it's just another syntax for what you can do already
  356. # [13:30] <mookid> what?
  357. # [13:30] <mookid> no you CANT..
  358. # [13:30] <Hixie> the video element adds a way to do video without paying adobe
  359. # [13:31] <mookid> if you can please tell me how
  360. # [13:31] <Hixie> instead of src="foo" accept="text/html" you do src="foo.html"
  361. # [13:31] <mookid> that's not the same thing
  362. # [13:31] <mookid> that's totally different
  363. # [13:31] <mookid> that's not HTTP conneg
  364. # [13:31] <Hixie> it acts exactly the same to the user
  365. # [13:31] <mookid> not to DEVELOPERS
  366. # [13:31] <mookid> who are the people
  367. # [13:31] <Hixie> yes but HTTP conneg, as previously discussed, is a bad idea
  368. # [13:31] <mookid> USING HTML
  369. # [13:31] <mookid> users dont SUE html
  370. # [13:31] <mookid> USE
  371. # [13:32] <mookid> they dont CARE about html
  372. # [13:32] <Hixie> developers are developing for the users
  373. # [13:32] <Hixie> so if the users see no difference...
  374. # [13:32] <mookid> they couldn't care less if it was XHTML HTML whatever
  375. # [13:32] <mookid> er..
  376. # [13:32] <mookid> yeah..
  377. # [13:32] <mookid> but what if the developers see a huge difference?
  378. # [13:32] * Quits: erlehmann (n=erlehman@p4FC11766.dip0.t-ipconnect.de) ("Ex-Chat")
  379. # [13:33] <mookid> what if it gives them a feasible way to use single URIs for many representations
  380. # [13:33] <mookid> that's not possible at the moment
  381. # [13:33] <Hixie> well in this paricular case, what difference do they see?
  382. # [13:33] <mookid> that's a big difference
  383. # [13:33] <mookid> well
  384. # [13:33] <mookid> not possible -> is now possible
  385. # [13:33] <hesslow> mookid: Why don't just use mod_rewrite and use the extension part as content-type?
  386. # [13:33] <mookid> that's more of a change than
  387. # [13:33] <mookid> crappy object and embed tags for video -> video tags for vide
  388. # [13:33] <hsivonen> mookid: you aren't considering things on high enough a level of abstraction
  389. # [13:34] <Hixie> what is possible now that wasn't before?
  390. # [13:34] <hsivonen> mookid: when you go high enough, the Accept header is just an implementation detal
  391. # [13:34] <hsivonen> detail
  392. # [13:34] <mookid> hesslow: I know you can do that.. that's what I do at the moemnt
  393. # [13:34] <mookid> everyone does it that way
  394. # [13:34] <mookid> because you cant do it any other way
  395. # [13:34] <mookid> because HTTP conneg isnt supported
  396. # [13:34] <mookid> you can make a browser GUI that makes use of HTTP conneg
  397. # [13:34] <hesslow> So as a developer is there any difference then?
  398. # [13:34] <mookid> so no one produces web apps that use http conneg
  399. # [13:35] <mookid> yes there's a huge difference
  400. # [13:35] <mookid> because you *can* use HTTP conneg
  401. # [13:35] <Hixie> as hsivonen says, the content negotiation pattern is supported, just not using the low-level implementation details of http vs uris
  402. # [13:35] <mookid> and so you *can* serve multiple content-types from one URI
  403. # [13:35] <Hixie> but that's an implementation detail
  404. # [13:35] <Hixie> it doesn't affect whether or not the pattern is possible
  405. # [13:35] <mookid> yes it does
  406. # [13:35] <Hixie> how?
  407. # [13:35] <mookid> it's completely different
  408. # [13:35] <Hixie> how?
  409. # [13:36] <mookid> well it's PROTOCOL level
  410. # [13:36] <Hixie> at the architectural level, how is it different?
  411. # [13:36] <mookid> masively
  412. # [13:36] <Hixie> how?
  413. # [13:36] <mookid> URI strcture?
  414. # [13:36] <mookid> cachine mechanisms
  415. # [13:36] <mookid> caching
  416. # [13:36] <Hixie> that's an implementation detail, not an architectural level detail
  417. # [13:36] <Hixie> i'm asking what difference does it make at the architecture level
  418. # [13:36] <hsivonen> caching has to happen on the representation level anyway
  419. # [13:37] <mookid> Vary
  420. # [13:37] <Philip`> If you encode the desired content-type in the URI, it's not possible for a general-purpose HTTP-processing device to understand what's the resource identifier and what's the content-type selector, because there's no standard for encoding that stuff in URIs
  421. # [13:37] <mookid> yes exactly
  422. # [13:37] <mookid> which means that if you were using HTTP conneg
  423. # [13:38] <mookid> and your brwoser knew it was only requesting text/html
  424. # [13:38] <Hixie> Philip`: such a standard or convention could be easily established
  425. # [13:38] <hsivonen> Philip`: is that a problem?
  426. # [13:38] <mookid> youc ould implement security mechanism
  427. # [13:38] <mookid> to reject that content
  428. # [13:38] <mookid> yes
  429. # [13:38] <mookid> read what I just wrote
  430. # [13:38] <mookid> is one example of the benefits
  431. # [13:38] <mookid> of UNIFORMITY
  432. # [13:38] <Philip`> whereas there is a standard for encoding the resource identifier in the URI and the content-type selector in Accept, so devices that don't know about your application-specific encoding mechanism can still separate the resource/representation identifiers
  433. # [13:38] <hesslow> Are there any good way to do fallback for your own protocols-handlers? I found the type-attribute on a-tags for content-type but there is no way to specify how the fallback should be done. What I would want is a fallback to a normal http-uri if the browser don't support the protocol
  434. # [13:39] <jcranmer> mookid: the sever need not match the Accept header
  435. # [13:39] <mookid> exactly..
  436. # [13:39] <mookid> so if it doesnt
  437. # [13:39] <mookid> there's a standard way of sayign
  438. # [13:39] <mookid> 'hey look I wasnt expecting that'
  439. # [13:39] <mookid> if it's in the URI
  440. # [13:39] <mookid> that's not feasible
  441. # [13:39] <mookid> ?type=html ;type=text/html .html
  442. # [13:40] <Philip`> Hixie: You couldn't establish it in a way that wouldn't conflict with other people not following that standard and perfectly legitimately happening to use the same magic URI query parameter or whatever the content-type thing is stored as
  443. # [13:40] <mookid> you couldn't ?
  444. # [13:41] <mookid> dunno if I'm reading that right
  445. # [13:41] <Hixie> Philip`: yeah, fair point
  446. # [13:42] <Philip`> hsivonen: I don't know if it's a practical problem or not, since it depends on whether general-purpose HTTP-processing devices can do interesting things with that information
  447. # [13:42] <Hixie> Philip`: but it's unclear that the convention needs to extend beyond the server
  448. # [13:42] <Hixie> Philip`: (i'm not sure i understand the use cases)
  449. # [13:42] <mookid> well the security mechnism would be nice..
  450. # [13:43] <Philip`> mookid: I mean you couldn't define a standard which says e.g. ?type=text/html in the URI is equivalent to Accept:text/html, because that would conflict with people who happen to use ?type=... for something else
  451. # [13:43] <mookid> yeah that's what I mean
  452. # [13:43] <mookid> it's not uniform
  453. # [13:43] <mookid> so you couldn't reaasonably protect against that
  454. # [13:43] <mookid> if it's inteh accept header that a certain request is expected to be only text/html or text/* or whateevr
  455. # [13:44] <mookid> and it's outside of that
  456. # [13:44] <mookid> you can throw errors or whatever
  457. # [13:44] <mookid> you cant do that if it's in the URI
  458. # [13:44] <Philip`> Why bother with sending Accept? Just send a normal request, and if you don't get the text/html you expected then throw it away
  459. # [13:45] <mookid> As a security feature - thre's probably something you could do to prevent CSRF/XSS
  460. # [13:45] <mookid> particularly if the HTML is all modular and stuf
  461. # [13:45] <mookid> modularity is great functionality but it's going to make CSRF and XSS go nuts
  462. # [13:45] <Hixie> CSRF wouldn't be helped here since the page containing the markup would be the source page
  463. # [13:46] <Philip`> mookid: That's sounding incredibly vague :-p
  464. # [13:46] <Hixie> and XSS as far as I can tell wouldn't happen with a link, and we've already got sandbox="" for <iframe>
  465. # [13:46] <mookid> :/
  466. # [13:46] <mookid> so you dont take the point that its easier to implement a security mechanism against HTTP conneg?
  467. # [13:47] <Philip`> If there is a specific instance of some vulnerability that could best be solved by this mechanism, then that'd be more useful than saying "there's probably something you do [with this feature]"
  468. # [13:47] <mookid> well yeah sure I can go away and come up with the case if you like
  469. # [13:47] <mookid> I mean
  470. # [13:47] <mookid> it's hard to deny that's the case
  471. # [13:48] <mookid> Either way - I think you an I agree that it is a significantly different approach to aplpication development
  472. # [13:48] <Philip`> s/you do/you could do/
  473. # [13:48] <mookid> particularly from the server standpoint
  474. # [13:48] <mookid> of data store
  475. # [13:48] <mookid> and representations
  476. # [13:49] <mookid> + it's not imcompatible with the current methods
  477. # [13:49] <Philip`> I don't think it's significantly different - it's just a different syntax, and that syntax might make a few things work better and a few things work worse
  478. # [13:49] <mookid> the only worse is how do I know what this string URI means
  479. # [13:50] * Parts: zcorpan (n=zcorpan@pat.se.opera.com)
  480. # [13:50] * Quits: annevk2 (n=annevk@77.163.243.203) (Read error: 54 (Connection reset by peer))
  481. # [13:50] * Joins: annevk2 (n=annevk@77.163.243.203)
  482. # [13:51] <mookid> in a business context there's only so many UAs to account for
  483. # [13:51] <mookid> and natural lanaguage goes along way aswell
  484. # [13:51] <mookid> god forbid we should humanise human computer interaction
  485. # [13:52] <mookid> -_--
  486. # [13:52] <mookid> but hey thats all 'moon' stuff
  487. # [13:55] * Quits: olliej (n=oliver@219.89.238.104)
  488. # [13:56] <Philip`> Why humanise it? I don't like humans
  489. # [13:58] <Philip`> Natural language doesn't seem great - "Visit whatwg.org in your web browser then click "HTML5" in the "Specs" box" is much less helpful to anyone than "Visit http://whatwg.org/html5", and the uniformity is a significant benefit of URIs
  490. # [13:59] <jcranmer> most computer problems emabate from between the chair and monitor
  491. # [13:59] <jcranmer> s/b/n/
  492. # [14:00] <Philip`> That's a very old-fashioned pre-mobile view of the world :-p
  493. # [14:01] * Joins: myakura (n=myakura@p4200-ipbf2306marunouchi.tokyo.ocn.ne.jp)
  494. # [14:01] <jcranmer> ok then
  495. # [14:02] <jcranmer> most problems emanate from devices running at less than 1 KHz clock speed :-)
  496. # [14:02] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  497. # [14:04] * Quits: webben (n=webben@nat/yahoo/x-b7e50a750b319c74) (Read error: 145 (Connection timed out))
  498. # [14:05] * Joins: aaronlev_ (n=chatzill@f051115131.adsl.alicedsl.de)
  499. # [14:09] <Philip`> jcranmer: So it's all EDSAC's fault?
  500. # [14:10] * Quits: aaronlev (n=chatzill@f051115131.adsl.alicedsl.de) (Read error: 60 (Operation timed out))
  501. # [14:10] * aaronlev_ is now known as aaronlev
  502. # [14:10] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  503. # [14:11] <Hixie> wtf, now my plugin works in firefox but in safari only the name components are shown, not the values!
  504. # [14:12] * Quits: webben_ (n=webben@nat/yahoo/x-adba837f75155fa4) (Read error: 110 (Connection timed out))
  505. # [14:12] <Hixie> and it works fine now.
  506. # [14:12] <Hixie> ok.
  507. # [14:12] <Hixie> fine.
  508. # [14:13] <Hixie> whatever.
  509. # [14:13] <Hixie> i don't care.
  510. # [14:13] <Hixie> :-P
  511. # [14:14] <BenMillard> krijnh, this should be an IRC logs tagline: http://krijnhoetmer.nl/irc-logs/whatwg/20081120#l-283
  512. # [14:14] <Philip`> s/design/party/
  513. # [14:14] * BenMillard forgot the keg...
  514. # [14:16] <BenMillard> Philip`, the ".html" or ".pdf" or ".png" and suchlike portion of URIs is already a widespread convention for selecting particular content types (re: http://krijnhoetmer.nl/irc-logs/whatwg/20081120#l-420)
  515. # [14:17] <BenMillard> Hixie, that convention is used outside of servers: browser extensions sometimes use RegExp on URIs in the DOM to figure out what type of thing they are pointing to, and give special behaviour for them
  516. # [14:17] <BenMillard> I'm not saying that's a good idea, though...
  517. # [14:18] <mookid> no that's terible and totally impractical -_-
  518. # [14:18] <Philip`> You should probably use <a href type> for that
  519. # [14:19] <Philip`> (if it's purely client-side)
  520. # [14:19] <Philip`> (and if you're in control of the content)
  521. # [14:19] <mookid> why type and not accept?
  522. # [14:19] <BenMillard> Philip`, the extensions are designed to work on the web :)
  523. # [14:19] <mookid> what are extensions?
  524. # [14:19] <Philip`> mookid: Because type is advisory information indicating the expected type of the thing at the URI
  525. # [14:20] <mookid> so.. the accept header?
  526. # [14:20] <BenMillard> mookid: AKA browser add-ons
  527. # [14:20] <Philip`> mookid: so it's quite similar to the file extension, in that it doesn't affect the request at all
  528. # [14:20] <mookid> but then you're just attempting a hybrid of http conneg and URI conneg
  529. # [14:20] <Philip`> BenMillard: Ah, fair enough :-)
  530. # [14:21] <mookid> if you're admitting there are cases where you would want to indicate what type a link should be
  531. # [14:21] <Philip`> mookid: It's not attempting any kind of conneg at all - it's just a way for an HTML document to tell clients what might be the content-type of a URI, so they can add "warning: this link is probably a PDF and may crash your browser" to the links or whatever
  532. # [14:21] <mookid> you're kind of producing the 'illusive' use case
  533. # [14:22] <Philip`> and it doesn't involve the server at all
  534. # [14:22] <mookid> that's what Accept does
  535. # [14:22] <mookid> no not as it stands
  536. # [14:22] <mookid> it could
  537. # [14:22] <mookid> if it was connected to the Accept request
  538. # [14:22] <mookid> of that request implied
  539. # [14:22] <BenMillard> Philip`, the one's I've tried are actually quite effective as file extensions seem almost ubiquitous and the main types you'd want special behaviour for are rarely in conflict with other types
  540. # [14:22] <mookid> by the link
  541. # [14:23] <BenMillard> Philip`, it also means the feature (such as grouping links by the type of thing they point to) works without sending loads of HEAD requests and waiting for the responses
  542. # [14:23] <mookid> Accept header of the request implied by the link*
  543. # [14:24] <mookid> it woudl be really cool if we could get to a stage where HTTP was encouraged to develop a standard way of indicating available content types
  544. # [14:24] <mookid> then if someone sends you a URL
  545. # [14:24] <Philip`> mookid: But for these particular use cases, there's no need to make it send the Accept header or anything, because it's just informing the client about stuff
  546. # [14:24] <mookid> you right click it and get a context-menu 'open with'
  547. # [14:24] <mookid> and it lists your UAs for the content types available
  548. # [14:24] <mookid> that would be sweet :)
  549. # [14:26] <Philip`> That does sound like it could be quite useful
  550. # [14:26] * Philip` goes away for a while
  551. # [14:26] <mookid> yeah that will never be encouraged unless browsers encourage http conneg
  552. # [14:26] <mookid> it's chicken and egg
  553. # [14:27] <mookid> it's definitely a different way of thinking about URIs though
  554. # [14:27] <mookid> browsers dominate HTTP applications so unless it's provisioned there it wont happen
  555. # [14:28] <Philip`> You could implement it by e.g. right-click "open with" triggering an HTTP request with a "Tell-Me-About-Extra-Content-Types" header, which legacy servers ignore and they send the default type, but new servers respond with a list of content-types and the client sends an extra request to get the one it wants, or something
  556. # [14:28] <mookid> yeah
  557. # [14:28] <mookid> exactly
  558. # [14:29] <Philip`> (But then that's a purely HTTP thing, not HTML)
  559. # [14:29] <mookid> well I jsut mentioned above
  560. # [14:29] <mookid> brwosers dominate HTTP app dev
  561. # [14:29] <mookid> all the frameworks are designed for them
  562. # [14:29] <mookid> so they focus on using URIs
  563. # [14:30] <BenMillard> Philip` & mookid, sounds like you want the browser to trigger a 300 Multiple Choices response: http://tools.ietf.org/html/rfc2616#section-10.3.1
  564. # [14:30] <mookid> the whole process is way more oslid using protocol level conneg
  565. # [14:31] <Philip`> "If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field" - so you need a separate URI per representation?
  566. # [14:31] <Philip`> Anyway, I'm going away for a while :-p
  567. # [14:32] <mookid> Philip` ftw?
  568. # [14:32] <BenMillard> Philip`, I imagine it expects a filetypeless cononical URLs like /foo with a set of filetyped URLs like /foo.bar and /foo.baz and these are what get listed in the reponse it sends
  569. # [14:32] <BenMillard> s/cononical URLs/cononical URL/
  570. # [14:33] <mookid> or is it foo?type=bar
  571. # [14:33] <mookid> or foo?content-type=bar
  572. # [14:33] <mookid> foo;type=bar
  573. # [14:33] <BenMillard> mookid, although which identifies the type of the resource, yeah
  574. # [14:34] <BenMillard> s/although/anything/
  575. # [14:34] * BenMillard wonders how that typo happened...
  576. # [14:34] <mookid> yeah it's just creating ambiguity and resource blaot where its not necessary
  577. # [14:34] <mookid> bloat^
  578. # [14:34] <mookid> HTTP handles this nicely
  579. # [14:34] <BenMillard> huh? that *is* the HTTP spec :|
  580. # [14:34] <BenMillard> well, cya
  581. # [14:35] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  582. # [14:35] <mookid> well the http spec actually mentions both methods
  583. # [14:35] <mookid> oh, bye
  584. # [14:35] <mookid> ABORT ABORT!
  585. # [14:35] <mookid> :>
  586. # [14:39] * Quits: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  587. # [14:39] * Quits: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  588. # [14:46] <mookid> another key point here is that if users are using PUT to update resources.. how are they to know wheher PUT /document.pdf updates /document.html and /document.xml - it's ambiguous
  589. # [14:47] <mookid> if the URI is the same this is completely clear
  590. # [14:47] <mookid> added to which - as soon as the PUT is performed on that URI - the caches can pick up on this and react for all representations to be re-cached
  591. # [14:48] <mookid> this isn't possible if the URIs are different per resource
  592. # [14:48] <mookid> yoru caching mechanism has to be application aware
  593. # [14:51] <mookid> ^ this is just an example of how doing the conneg in HTTP makes significant changes to development approach
  594. # [14:53] <Hixie> wow, httpbis is already up to 300 pages
  595. # [14:54] * Joins: aaronlev_ (n=chatzill@g228083009.adsl.alicedsl.de)
  596. # [14:54] <Hixie> http 1.1 was only 176
  597. # [14:54] <Hixie> i thought http bis wasn't adding anything new?
  598. # [14:54] <mookid> I dont know I'm not involved with that right now
  599. # [14:54] <mookid> how far away is that?
  600. # [14:55] <mookid> Hixie: do you even accept that it is different and has benefits?
  601. # [14:56] <mookid> I'm not getting at you it just frustrates me that I can articulate it properly :)
  602. # [14:56] <mookid> can't^
  603. # [14:57] <mookid> I'll take that as a yes then.. -_-
  604. # [15:01] <ehird> wow
  605. # [15:01] <ehird> mookid is STILL on about conneg?!?!?!
  606. # [15:01] <ehird> :o
  607. # [15:01] <jcranmer> ehird: it's only been >48 hours
  608. # [15:11] <mookid> well I don't think it's as cut and dry as you seem to believe it is
  609. # [15:12] <mookid> other than the fact that there's no way I can get this past the protector of the internet
  610. # [15:12] * Joins: csarven (n=csarven@modemcable150.182-202-24.mc.videotron.ca)
  611. # [15:13] * Quits: aaronlev (n=chatzill@f051115131.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  612. # [15:14] * Joins: webben (n=webben@nat/yahoo/x-ca5a78b27bd19028)
  613. # [15:14] * Joins: webben_ (n=webben@nat/yahoo/x-91d528a6b281416f)
  614. # [15:15] * Quits: billyjackass (n=MikeSmit@58.157.21.205) ("sex break")
  615. # [15:20] * Quits: myakura (n=myakura@p4200-ipbf2306marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  616. # [15:25] <takkaria> PROTECTOR OF THE INTERNETES
  617. # [15:26] * krijnh adds a new subtitle to his logs
  618. # [15:27] <mookid> he talked to me
  619. # [15:27] <mookid> I am blessed
  620. # [15:27] <mookid> thanks be to Neo
  621. # [15:29] <mookid> don't tell him about javascript it'll break his little heart
  622. # [15:29] <mookid> :P
  623. # [15:31] <krijnh> It'll wake him up now, mostly :)
  624. # [15:33] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Remote closed the connection)
  625. # [15:33] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  626. # [15:34] * Joins: smerp (n=smerp@66.192.95.199)
  627. # [15:39] * Joins: eric_carlson (n=ericc@nat/apple/x-5531a2cd5b99ec13)
  628. # [15:43] <Dashiva> ehird: This is nothing compared to alt, alt 2: the return of alt, alt 3: son of alt, and all the others yet to come
  629. # [15:43] <ehird> :D
  630. # [15:44] <ehird> who's gonna by connegcube.com
  631. # [15:44] <ehird> 4-day harmonic content negotiation
  632. # [15:46] <mookid> lies!
  633. # [15:46] <mookid> what a dissapointment that was
  634. # [15:48] * Joins: Hish (n=chatzill@mail2.n-e-s.de)
  635. # [15:48] <Dashiva> ehird: Site doesn't work :<
  636. # [15:49] <ehird> *buy
  637. # [15:49] <ehird> well duh i was asking for someone to make it
  638. # [15:49] <ehird> :D
  639. # [15:52] * Joins: eric_carlson_ (n=ericc@nat/apple/x-edad580f00f2b43b)
  640. # [15:53] <Dashiva> Oh snap, new last week
  641. # [15:54] <annevk2> poor quality lately
  642. # [16:08] * Joins: tndH (n=Rob@james-baillie-pc083-058.student-halls.leeds.ac.uk)
  643. # [16:09] * Quits: eric_carlson (n=ericc@nat/apple/x-5531a2cd5b99ec13) (Read error: 110 (Connection timed out))
  644. # [16:10] * Quits: tthorsen (n=tommy@home.kvaleberg.no) ("Leaving")
  645. # [16:16] * Joins: dimich (n=dimich@ip67-152-86-163.z86-152-67.customer.algx.net)
  646. # [16:25] <Philip`> "Mr last Week sez: ... tone down the insults and rhetoric, it is uncalled for" - ooh, irony
  647. # [16:29] * Joins: aroben (n=aroben@unaffiliated/aroben)
  648. # [16:39] * Quits: annevk2 (n=annevk@77.163.243.203) (Remote closed the connection)
  649. # [16:40] * Joins: billmason (n=bmason@ip41.unival.com)
  650. # [16:45] * Joins: erlehmann (n=erlehman@dslb-088-072-031-063.pools.arcor-ip.net)
  651. # [16:45] <webben_> What's the current thought on how should inline stage directions/descriptions be handled in DIALOG?
  652. # [16:46] * Joins: mstange (n=markus@aixd3.rhrk.uni-kl.de)
  653. # [16:58] <webben_> or multiblock speeches...
  654. # [17:01] * Quits: dave_levin_ (n=levin@72.14.224.1)
  655. # [17:02] * Quits: dimich (n=dimich@ip67-152-86-163.z86-152-67.customer.algx.net)
  656. # [17:06] * Quits: maikmerten (n=merten@129.217.26.195) (Remote closed the connection)
  657. # [17:06] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  658. # [17:13] * Joins: pergj__ (n=pergj@cm-84.208.140.163.getinternet.no)
  659. # [17:14] * aroben is now known as aroben|away
  660. # [17:20] <mookid> Philip`: did you have any more thoughts on it?
  661. # [17:21] <Philip`> mookid: On what in particular?
  662. # [17:21] * Quits: jwalden (n=waldo@c-67-180-39-55.hsd1.ca.comcast.net) (Read error: 145 (Connection timed out))
  663. # [17:26] <mookid> whether there is a significant difference in HTTP conneg, and whether it's provision is compatible with conneg in URI
  664. # [17:27] * Joins: dbaron (n=dbaron@c-71-204-144-136.hsd1.ca.comcast.net)
  665. # [17:27] * Quits: weinig_ (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  666. # [17:40] * Quits: starjive (i=beos@213-66-217-32-no30.tbcn.telia.com)
  667. # [17:45] <Philip`> mookid: I can't think of any more thoughts at the moment
  668. # [17:47] <mookid> ok just chicken
  669. # [18:04] * Joins: smedero (n=smedero@mdp-nat251.mdp.com)
  670. # [18:06] <Philip`> Oh no, #html-wg got invaded
  671. # [18:07] <Philip`> hsivonen: Continuing my comment from there: (and making the spec intentionally complex and obscure in order to discourage people writing their own probably-buggy XML parsers when they should be using a library instead, seems kind of elitist (that's not quite the right term but I can't think of the right one))
  672. # [18:08] <Philip`> Wow, someone just made Gmail ugly
  673. # [18:08] <Philip`> Hmm, it's a bit better if I reload the whole page and it's not mixing the old and new themes...
  674. # [18:10] <gavin> omgchange!
  675. # [18:11] * Joins: dave_levin (n=levin@nat/google/x-208e0532927e090d)
  676. # [18:11] <Philip`> Hmm, the layout is still different, and therefore ugly
  677. # [18:12] * Joins: dimich (n=dimich@nat/google/x-37d19bdf3527d328)
  678. # [18:12] <Philip`> Judging by what happened when they last upgraded everything, I will be terribly upset for about two days and then I will be used to it and it'll seem perfectly normal
  679. # [18:12] <gavin> heh, indeed
  680. # [18:12] * Joins: dglazkov (n=dglazkov@nat/google/x-5cb85c407376373c)
  681. # [18:13] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  682. # [18:15] * Quits: dimich (n=dimich@nat/google/x-37d19bdf3527d328) (Client Quit)
  683. # [18:15] * Quits: dave_levin (n=levin@nat/google/x-208e0532927e090d) (Client Quit)
  684. # [18:18] * Joins: dave_levin (n=levin@nat/google/x-57a33b844763fb32)
  685. # [18:19] * Quits: mstange (n=markus@aixd3.rhrk.uni-kl.de) ("ChatZilla 0.9.84 [Firefox 3.1b2pre/20081118020315]")
  686. # [18:20] <Philip`> Hmph, Jim Jewett seems to think my name on IRC is a typo :-(
  687. # [18:21] <Philip`> (when actually it's just me being far too unimaginative to come up with a decent name, and someone else having already registered "Philip" on this network)
  688. # [18:22] * Quits: pesl (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
  689. # [18:24] * Joins: dimich (n=dimich@nat/google/x-48282b85076a3c40)
  690. # [18:27] <mookid> imagine if caching was controlled just with the Vary header
  691. # [18:27] * Quits: dave_levin (n=levin@nat/google/x-57a33b844763fb32)
  692. # [18:27] <mookid> that would be fricking awesome
  693. # [18:28] <Philip`> But impossible
  694. # [18:28] <mookid> not for new apps
  695. # [18:28] <mookid> if your GUI and your API are the same interface
  696. # [18:28] <mookid> one being the HTML representation and the other being JSON or XML
  697. # [18:29] <Philip`> If you have multiple formats for some resource, but it takes a few minutes to do the conversion (because it's expensive transcoding or OCRing or whatever), how would you handle cache invalidation once the new format has been generated?
  698. # [18:29] * Joins: dave_levin (n=levin@nat/google/x-045cb5fb2e471bde)
  699. # [18:29] <mookid> gah? -_-
  700. # [18:31] <Philip`> Nicely-designed apps shouldn't block users who are uploading data while the server does a load of back-end computation - asynchrony is more user-friendly, but doesn't seem to interact well with the assumptions made by caches
  701. # [18:31] <mookid> why would that be the case? yuo don't have to cache the entire of your application
  702. # [18:32] <mookid> you should only be caching what's appropriate to cache. -_-
  703. # [18:32] <mookid> you can control that with your responses
  704. # [18:34] * Quits: dave_levin (n=levin@nat/google/x-045cb5fb2e471bde) (Read error: 104 (Connection reset by peer))
  705. # [18:41] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
  706. # [18:47] * Quits: aaronlev_ (n=chatzill@g228083009.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  707. # [18:49] <Dashiva> No worries about keeping warm this winter as long as public-html stays as it is. :)
  708. # [18:51] * Philip` wonders why Textile parses "@,@ _x_@x@" correctly, but not "@, @_x_@x@"
  709. # [18:52] * Joins: maikmerten (n=maikmert@Lacf4.l.pppool.de)
  710. # [18:54] * Joins: rillian (n=giles@66.183.19.247)
  711. # [18:55] <Dashiva> The former looks like two smileys on a seesaw, the latter looks like some weird mutant and something
  712. # [18:57] <Philip`> The latter parses into <code>, @&lt;em&gt;x&lt;/em&gt;@x</code>, which surely can't be intentional
  713. # [19:00] * Joins: dave_levin (n=dave_lev@nat/google/x-94321c6b5ad20e25)
  714. # [19:07] <Dashiva> Philip`, you just got told
  715. # [19:08] <Philip`> Indeedily
  716. # [19:09] <Dashiva> Anything you would like to tell our viewers?
  717. # [19:10] <Philip`> No
  718. # [19:10] * Joins: weinig_ (n=weinig@17.203.15.141)
  719. # [19:11] <Dashiva> What will you do next?
  720. # [19:11] <Philip`> Nobody knows - that's how crazy I am
  721. # [19:12] <Philip`> so you better keep watching!
  722. # [19:14] <Dashiva> You heard him. Don't change that channel!
  723. # [19:37] * Quits: pergj__ (n=pergj@cm-84.208.140.163.getinternet.no) (Read error: 60 (Operation timed out))
  724. # [19:45] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl) (Connection timed out)
  725. # [19:45] <gsnedders> Philip` pwn'd on last week :)
  726. # [19:49] * Joins: mstange (n=markus@aixd3.rhrk.uni-kl.de)
  727. # [19:51] * Quits: danbri (n=danbri@unaffiliated/danbri)
  728. # [19:55] * Quits: mpt (n=mpt@canonical/launchpad/mpt) ("Leaving")
  729. # [20:04] * Quits: sicking (n=chatzill@63.245.220.242) (Remote closed the connection)
  730. # [20:04] * Quits: dimich (n=dimich@nat/google/x-48282b85076a3c40)
  731. # [20:04] * Joins: jwalden (n=waldo@guest-225.mountainview.mozilla.com)
  732. # [20:05] * Quits: dave_levin (n=dave_lev@nat/google/x-94321c6b5ad20e25)
  733. # [20:08] * Joins: danbri (n=danbri@ip565f6edb.direct-adsl.nl)
  734. # [20:09] * Joins: dave_levin (n=dave_lev@nat/google/x-18bdc1ad39c318ff)
  735. # [20:13] * Joins: aaronlev_ (n=chatzill@g228083009.adsl.alicedsl.de)
  736. # [20:13] * aaronlev_ is now known as aaronlev
  737. # [20:15] * Quits: ap (n=ap@195.239.126.10)
  738. # [20:15] * Joins: yecril71 (n=giecrilj@piekna-gts.2a.pl)
  739. # [20:21] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  740. # [20:26] * Joins: jwalden_ (n=waldo@corp-241.mountainview.mozilla.com)
  741. # [20:28] * Quits: dbaron (n=dbaron@c-71-204-144-136.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  742. # [20:32] * Quits: danbri (n=danbri@unaffiliated/danbri) (Read error: 110 (Connection timed out))
  743. # [20:32] * Quits: mstange (n=markus@aixd3.rhrk.uni-kl.de) ("ChatZilla 0.9.84 [Firefox 3.1b2pre/20081118020315]")
  744. # [20:35] * Joins: roc (n=roc@121-72-209-122.dsl.telstraclear.net)
  745. # [20:40] * Quits: roc (n=roc@121-72-209-122.dsl.telstraclear.net) (Client Quit)
  746. # [20:41] * Quits: jwalden (n=waldo@guest-225.mountainview.mozilla.com) (Read error: 110 (Connection timed out))
  747. # [20:44] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  748. # [20:46] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  749. # [20:55] <yecril71> Philip`, could you look at my test page in IE8 today?
  750. # [20:55] <yecril71> Is there a chance for the section headers in HTML5 show up in IE7?
  751. # [20:56] <yecril71> It is very inconvenient that they do not
  752. # [20:56] <yecril71> You do not know what you are reading about
  753. # [20:56] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  754. # [21:00] <yecril71> Where is OBJECT[classid] declared?
  755. # [21:01] * Joins: olliej (n=oliver@219.89.238.104)
  756. # [21:01] <yecril71> I cannot find it in the green summary box
  757. # [21:01] <gsnedders> yecril71: it's non-conforming, so nowhere
  758. # [21:03] <yecril71> But it is still mentioned in the text
  759. # [21:03] <yecril71> "If the classid attribute is present, and has a value that isn't the empty string,"
  760. # [21:04] <gsnedders> It has defined processing for UAs
  761. # [21:04] <gsnedders> Just because it has defined processing doesn't make it conforming
  762. # [21:04] <yecril71> Was that present perfect, or present simple?
  763. # [21:05] <gsnedders> present simple
  764. # [21:06] <yecril71> Thx
  765. # [21:06] * gsnedders should be less ambiguous
  766. # [21:07] <takkaria> can someone explain to me the difference? :)
  767. # [21:08] <gsnedders> takkaria: Yes
  768. # [21:08] <yecril71> Present simple is the verb itself, inflected, followed by the object.
  769. # [21:09] <yecril71> Present perfect is aux "have" + past participle, followed by the object.
  770. # [21:09] <Dashiva> The ambiguity lies in whether defined is used as a participle or as an adjective
  771. # [21:10] <gsnedders> What can I put on my CV about WHATWG?
  772. # [21:10] <Dashiva> "Official inner-circle teamster"
  773. # [21:11] <yecril71> What should happen to embeeded ActiveX objects then?
  774. # [21:11] <gsnedders> Dashiva: Not a fanboy.
  775. # [21:11] <yecril71> I understand type="application/x-oleobject", but what about the CLSID?
  776. # [21:12] <yecril71> Where do I put it, given that classid is out?
  777. # [21:13] <yecril71> s/embeeded/embedded/
  778. # [21:14] * Joins: annevk2 (n=annevk@77.163.243.203)
  779. # [21:15] * Quits: dave_levin (n=dave_lev@nat/google/x-18bdc1ad39c318ff)
  780. # [21:16] <yecril71> classid is not mentioned as a difference from HTML4
  781. # [21:16] <gsnedders> Then the diff dsoc is wrong :)
  782. # [21:16] <gsnedders> *doc
  783. # [21:17] <yecril71> I would be glad to update it, but I need some information on how the decision was taken.
  784. # [21:17] <annevk2> feel free to blame me or submit patches to some mailing list I read
  785. # [21:18] <yecril71> I can do it myself, patches are excessive
  786. # [21:18] <annevk2> I actually think classid is still being considered for inclusion, using some hardcoded mapping table of values and plugins
  787. # [21:18] <Philip`> yecril71: Embedded ActiveX objects are not at all interoperable between platforms, so it wouldn't make much sense for HTML5 to provide specific syntax for them
  788. # [21:19] <Philip`> The conforming thing to do is to not use ActiveX :-)
  789. # [21:19] <Philip`> yecril71: I could look at your page, if you remind me where it is
  790. # [21:19] <annevk2> Philip`, you could make it interoperable if you map the classid to NPAPI
  791. # [21:20] <yecril71> <http://www.2a.pl/~ne01026/test.htm>
  792. # [21:20] <Philip`> How odd, IE8 can't even render Google search result pages non-buggily :-/
  793. # [21:20] <gsnedders> hmmm
  794. # [21:21] <gsnedders> logs missed the link to jgraham='s CV
  795. # [21:21] <Philip`> (It cut off after 1.5 results (but still showed the footer after that), until I selected some text and then the rest popped into existence)
  796. # [21:21] <jgraham> gsnedders: I didn' link to my CV :)
  797. # [21:21] <gsnedders> jgraham: Didn't you?
  798. # [21:21] <yecril71> That would be good, talking about an undefined attribute is rather strange
  799. # [21:22] <yecril71> It is better to say classid (deprecated) than nothing at all.
  800. # [21:23] <yecril71> It is possible not to use ActiveX and delegate all processing to server,
  801. # [21:23] <annevk2> we've taken the approach to only mention things when there's an effect or when they're allowed for convenience
  802. # [21:23] <yecril71> or to use application/java.
  803. # [21:23] <annevk2> currently neither is the case as far as HTML5 is concerned
  804. # [21:23] <annevk2> though as I said that might be changing
  805. # [21:23] <yecril71> classid has a defined effect, only itself is undefined.
  806. # [21:24] <Philip`> yecril71: Both columns look the same (except for the left one being narrower), and about the same as in Opera and Firefox - there's an "a" slightly above (overlapping) the horizontal line, and a "b" slightly below (also overlapping) the line
  807. # [21:24] <yecril71> That is rather peculiar.
  808. # [21:24] <yecril71> That is good.
  809. # [21:24] <annevk2> UAs that would let it have effect would be non conforming per HTML5 as it stands today
  810. # [21:24] <yecril71> IE7 is broken in that regard.
  811. # [21:24] <yecril71> Thx a lot.
  812. # [21:25] <Philip`> yecril71: IE8 in IE7 bug compatibility mode is very different - there's no overlapping, and the left column has an extra blank line before the "b", which I assume is what IE7 does
  813. # [21:25] <yecril71> So it looks like, although it is not a blank line at all.
  814. # [21:26] <Philip`> Well, it's a line that's blank ;-)
  815. # [21:26] <yecril71> No, it is vertical space.
  816. # [21:26] <yecril71> A line is something, a space is lack of something ;-)
  817. # [21:27] <yecril71> The effect is described in item 1 of the embedding algorithm in HTML5.
  818. # [21:27] <yecril71> (of classid).
  819. # [21:28] <yecril71> So it takes precedence over anything else.
  820. # [21:28] <yecril71> And yet classid is undefined.
  821. # [21:29] <yecril71> The effect is conforming, only the attribute itself is nonconforming.
  822. # [21:30] <yecril71> ActiveX objects can be advantageous in an in-house application.
  823. # [21:30] <annevk2> ah, classid is already mentioned for browsers? ok
  824. # [21:30] <Philip`> <b>x<i>y</b>z</i> is non-conforming, but there are conformance requirements for how browsers must handle that, so it's not really any different with these nonconforming attributes
  825. # [21:30] <yecril71> The alternatives of using in-page java or a server-side process can be too expensive.
  826. # [21:31] <gsnedders> annevk2: Can we have more standards suckage?
  827. # [21:31] <yecril71> Except that B and I are defined and do not jump at the reader out of nowhere.
  828. # [21:32] <yecril71> And yet it would be nice to be able to validate the pages the components reside in.
  829. # [21:32] <yecril71> Without customizing the validator.
  830. # [21:33] <yecril71> Of course, one can always use HTML4 for that purpose,
  831. # [21:33] <yecril71> but what about HTML5?
  832. # [21:33] <yecril71> Is there a chance of getting a hint?
  833. # [21:33] <yecril71> (of course, IE *requires* classid now;
  834. # [21:34] <yecril71> assuming we can change it, what should it be changed to?)
  835. # [21:34] <gsnedders> yecril71: Nothing is as bad as the image element
  836. # [21:34] * Quits: smedero (n=smedero@mdp-nat251.mdp.com) (Read error: 104 (Connection reset by peer))
  837. # [21:34] * Joins: smedero (n=smedero@mdp-nat251.mdp.com)
  838. # [21:34] <gsnedders> (it is mentioned once, in the parser, where it gets converted to img)
  839. # [21:34] * Quits: smedero (n=smedero@mdp-nat251.mdp.com) (Client Quit)
  840. # [21:36] <yecril71> How about type="application/x-oleobject;classid={G-U-I-D}"?
  841. # [21:41] <annevk2> gsnedders, we'll resume shortly; not exactly sure when
  842. # [21:50] * Joins: weinig__ (n=weinig@17.203.15.152)
  843. # [21:53] * Joins: roc (n=roc@202.0.36.64)
  844. # [21:54] <roc> it's sad that some of the top-crash bugs we're seeing are caused by trojans
  845. # [21:54] * Joins: sbublava (n=stephan@77.117.210.181.wireless.dyn.drei.com)
  846. # [21:57] <takkaria> ah, that sucks :(
  847. # [21:57] <takkaria> but I guess it speaks for the stability of your product
  848. # [21:58] * Quits: weinig_ (n=weinig@17.203.15.141) (Read error: 145 (Connection timed out))
  849. # [21:58] <roc> I think for both us and Webkit the majority of top-crash bugs are actually Flash-related
  850. # [22:07] * Parts: sbublava (n=stephan@77.117.210.181.wireless.dyn.drei.com)
  851. # [22:08] * Joins: sbublava (n=stephan@77.117.210.181.wireless.dyn.drei.com)
  852. # [22:08] * Quits: maikmerten (n=maikmert@Lacf4.l.pppool.de) (Remote closed the connection)
  853. # [22:10] <yecril71> I do not understand how Tom Broyer got the need to have separate URLs for representations.
  854. # [22:11] <Dashiva> Maybe he doesn't agree they're representations?
  855. # [22:11] <yecril71> It does not follow from Fielding’s quote.
  856. # [22:14] <hsivonen> whose idea was it to start calling them URIs instead of URLs?
  857. # [22:15] * Joins: D|eheLL (n=lucifer@30.63.49.60.klj02-home.tm.net.my)
  858. # [22:16] * Parts: D|eheLL (n=lucifer@30.63.49.60.klj02-home.tm.net.my)
  859. # [22:16] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  860. # [22:19] <yecril71> Seems like OP’s.
  861. # [22:21] <yecril71> Although Fielding uses the term "identifier", so that misuse can be probably traced to the boss.
  862. # [22:22] <yecril71> s/misuse/unneeded generalization/
  863. # [22:29] <ehird> eh, it makes sense
  864. # [22:29] <ehird> how do you locate <tel:...>
  865. # [22:34] * Joins: olliej_ (n=oliver@219.89.238.104)
  866. # [22:35] * Quits: olliej (n=oliver@219.89.238.104) (Read error: 104 (Connection reset by peer))
  867. # [22:38] * olliej_ is now known as olliej
  868. # [22:46] * Joins: dimich (n=dimich@nat/google/x-5fac806ab6208f48)
  869. # [22:51] <yecril71> What is <tel:>?
  870. # [22:52] <yecril71> And does it implement content negotiation?
  871. # [22:55] <gsnedders> yecril71: tel is a uri scheme for telephone numbers
  872. # [23:01] * Quits: weinig__ (n=weinig@17.203.15.152)
  873. # [23:05] <takkaria> erk. I joined the debate
  874. # [23:05] <takkaria> ehird: you locate it by phoning it, surely?
  875. # [23:05] <takkaria> oh, right
  876. # [23:05] <takkaria> I missed the context. :)
  877. # [23:06] <yecril71> And what about callto:?
  878. # [23:06] <ehird> ok then, how do you locate isbn::
  879. # [23:06] <ehird> ("going to a bookstore and buying it" is not an answer)
  880. # [23:06] <yecril71> Wikipedia has a tool for that
  881. # [23:06] * Quits: heycam (n=cam@210-84-47-88.dyn.iinet.net.au) ("bye")
  882. # [23:07] <yecril71> And isbn: does not support content negotiation either.
  883. # [23:07] <ehird> what has content negotiation got to do with this
  884. # [23:08] <yecril71> It is being asked in the context of content negotiation.
  885. # [23:08] <takkaria> I missed the context
  886. # [23:08] <yecril71> Why content negotiation is advertised for URIs in general.
  887. # [23:08] <takkaria> I thought that it was a "what am I meant to do with a tel:" number question, not a URI vs URL question
  888. # [23:09] <takkaria> URL means Universal Republic of Love, anyway, Tim Bray told me so :)
  889. # [23:09] <yecril71> wanna cyber? ;-)
  890. # [23:09] * takkaria chortles
  891. # [23:10] <yecril71> Is tel: anything official?
  892. # [23:10] <yecril71> I have never seen tel:, only callto:
  893. # [23:11] <takkaria> I've seen tel: here and there
  894. # [23:11] <yecril71> Seems like by mistake
  895. # [23:11] <yecril71> Does ekiga register for tel:?
  896. # [23:14] <ehird> yecril71: timbl has it in his foaf file
  897. # [23:14] <ehird> somehow i doubt a mistake.
  898. # [23:16] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  899. # [23:17] * jwalden_ is now known as jwalden
  900. # [23:23] * Joins: sicking (n=chatzill@corp-242.mountainview.mozilla.com)
  901. # [23:25] <gsnedders> yecril71: http://www.iana.org/assignments/uri-schemes.html
  902. # [23:25] <Philip`> yecril71: RFC 3966
  903. # [23:25] <gsnedders> yecril71: Ns such thing as callto registered
  904. # [23:26] * gsnedders returns to Shakespeare
  905. # [23:28] <yecril71> I only wanted information, not a proof :-)
  906. # [23:28] <yecril71> Seems the people at Skype are illiterate
  907. # [23:35] * Joins: weinig_ (n=weinig@17.203.15.141)
  908. # [23:37] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  909. # [23:45] * Joins: doublec (n=chris@118-92-214-173.dsl.dyn.ihug.co.nz)
  910. # [23:48] * Joins: nessy (n=nessy@124-171-15-183.dyn.iinet.net.au)
  911. # [23:54] * Quits: sbublava (n=stephan@77.117.210.181.wireless.dyn.drei.com)
  912. # Session Close: Fri Nov 21 00:00:00 2008

The end :)