/irc-logs / freenode / #microformats / 2015-12-01 / end

Options:

Previous day, Next day

  1. # Session Start: Tue Dec 01 00:00:00 2015
  2. # Session Ident: #microformats
  3. # [00:02] * Joins: Calli (6ca2f57e@gateway/web/freenode/ip.108.162.245.126)
  4. # [00:04] <Calli> !tell tantek I had a spec comment on the 28th. Can you take a look and let me know if you need more info? http://krijnhoetmer.nl/irc-logs/microformats/20151128
  5. # [00:04] <Loqi> Ok, I'll tell him that when I see him next
  6. # [00:10] <Calli> I'm looking at the discussion on implied u- props from the 30th
  7. # [00:11] <@tantek> hello Calli
  8. # [00:11] <Loqi> tantek: Calli left you a message 7 minutes ago: I had a spec comment on the 28th. Can you take a look and let me know if you need more info? http://krijnhoetmer.nl/irc-logs/microformats/20151128
  9. # [00:15] <Calli> I have my own perspective on implied props: I'm afraid I'm not a fan overall and I haven't implemented them yet. Will be last thing I implement if at all.
  10. # [00:15] <Calli> hi Tantek
  11. # [00:16] <Calli> One reason for reluctance is that I'm looking at mem-constrained environment and I want to dump all unecessary data as soon as possible
  12. # [00:17] <@tantek> Calli - they are part of the tradeoff of a huge simplification for many 90% plus simple cases for publishers with a little bit of work on the part of parsers
  13. # [00:17] <Calli> the Implied name property in particular looks like it could be pretty large since it will often be text content
  14. # [00:18] <@tantek> it's simple economics math of lowering barriers for accuracy and work for publishers (across millions) vs. a bit of work for a handful of parser devs
  15. # [00:18] <@tantek> Calli - if you have specific examples where implied name causes a problem, please share them!
  16. # [00:18] <@tantek> we are actively looking into documenting and solving any such problems
  17. # [00:19] <@tantek> but they must be based in real world examples
  18. # [00:19] <@tantek> not just "could be"
  19. # [00:20] <Calli> Will do next time I see one
  20. # [00:21] <Calli> Yeah - I was seeing real word examples
  21. # [00:21] <Calli> Oh is this one:
  22. # [00:21] <Calli> http://pin13.net/mf2/?url=https://blog.roku.com/blog/2015/11/23/black-friday-deals-sneak-peek-roku-se-roku-3-roku-streaming-stick-tcl-roku-tv/
  23. # [00:23] <Calli> Must admit I have assumed this is from implied name - haven't researched to see if it's another issue
  24. # [00:28] <Calli> You may well be right about the simplification, but I am still in process of convincing myself of that. It's clear that the markup is simplified. It's not yet clear to me that the mental model for authoring is simplified or that maintenance of markup is simplified. I don't have firm conclusions at this point.
  25. # [00:30] <@tantek> the simplification was driven specifically by web developer / designer feedback about classic mf1 markup which required explicit markup for names, urls, photos which were so common, and seemed to always require adding extra markup
  26. # [00:31] <@tantek> and the response to the mf2 solutions from the web design / development community has been very positive
  27. # [00:31] <@tantek> some of that history has been documented on the wiki on the /microformats2 page
  28. # [00:32] <Calli> Sounds good. It's definitely an alternative to microdata and json that don't have implied props.
  29. # [00:34] <@tantek> indeed - the same web developers were very confused as to why microdata/rdfa/json would come up with even more wordy approaches than classic mf1
  30. # [00:35] <Calli> Do you want me to make the case? LOL
  31. # [00:35] * Joins: KartikPrabhu (~kartik@2602:306:3859:10e0:8dca:e7a8:ce0f:5b0f)
  32. # [00:41] <@tantek> Calli - nah, no need to spend time on it
  33. # [00:41] <@tantek> I mean unless you truly believe there is some ecosystem benefit to the microdata/rdfa/json approaches
  34. # [00:41] <@tantek> (ecosystem, as in not just "it makes parsing easier")
  35. # [00:42] <Calli> I believe it's a trade-off. I like "easy-to-parse", but I like "easy to explain", "easy to understand", "easy to write", and "easy to read" way more.
  36. # [00:46] <Calli> There's often trade-offs between easy-to-write and easy-to-read. It feels like microdata and microformats have different opinions about the relative importance of those.
  37. # [00:46] * Joins: gordonb (~gordonb@67-131-47-154.dia.static.qwest.net)
  38. # [00:48] * Joins: hober (~ted@unaffiliated/hober)
  39. # [00:49] <Calli> Anyway, it's probably clear, but I'm all for limiting the appearance of implied props so proposal to prevent an element that already has a use from contributing to implied prop sounds good. This change would mean that a different element could then provide the implied value though right?
  40. # [00:50] <@tantek> that is a good question
  41. # [00:50] <Calli> The change is not just that an implied prop would be suppressed in some additional cases, but that it could actually get a different value?
  42. # [00:50] <@tantek> I'm not sure that's a good (easily predictable) result
  43. # [00:51] <@tantek> I would prefer a more conservative approach, and that is that if the first element found (per the parsing spec) that could/should provide an implied property is suppressed by this new rule (by another explicit property of the same *- prefix on that element), then there is nothing implied for that property
  44. # [00:52] <@tantek> rather than some sort of weird fallback to another element
  45. # [00:52] <@tantek> that makes it easier to understand
  46. # [00:52] <@tantek> and provides an obvious encouragement for the publisher to be explicit in those cases (which I expect to the be the rare exception, not the 90%, and thus it makes sense to ask the publisher to be explicit)
  47. # [00:52] <Calli> I might be wrong - maybe the only-of-type requirement prevents what I suggested
  48. # [00:53] <@tantek> it should
  49. # [00:55] <Calli> Actually only-of-type in the existing spec isn't sufficient, would need language you suggest I think
  50. # [00:55] <Loqi> [[microformats2-parsing-issues]] http://microformats.org/wiki/index.php?title=microformats2-parsing-issues&diff=65334&oldid=65333&rcid=101723 * Tantek * (+97) /* implied properties when an explicit class is provided */ where to provide input to proposals
  51. # [00:55] <@tantek> If you agree with the proposed resolution to the issue, could you add your +1, and perhaps add your question / comment asking for that? http://microformats.org/wiki/microformats2-parsing-issues#implied_properties_when_an_explicit_class_is_provided
  52. # [00:56] <@tantek> "that" being the extra language to further clarify the case you noted
  53. # [00:56] <@tantek> like +1 with this change ...
  54. # [00:56] <@tantek> or +1 with this additional handling
  55. # [01:09] <Calli> OK. Need to think about it a bit. Did you consider a broader restriction:
  56. # [01:09] <Calli> Presence of any explicitly marked up p- property on the item (not element) prevents implied p- properties Presence of any explicitly marked up u- property on the item (not element) prevents implied u- properties
  57. # [01:09] <kylewm> tantek: could you clarify what is the use case here? "Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties."
  58. # [01:09] * Quits: gordonb (~gordonb@67-131-47-154.dia.static.qwest.net) (Quit: gordonb)
  59. # [01:13] <@tantek> kylewm - too long ago to easily reload that context in my head now / asynchronously - can you re-raise in person on Thursday and we can discuss then?
  60. # [01:14] <@tantek> Calli - I did, and specifically avoided it to prevent too much blocking of implied p-name
  61. # [01:15] <Calli> These are relevant test cases for whether the implied URL property would get a value from a different element or not:
  62. # [01:15] <Calli> TC1: <div class="h-x"><a href="alink"></a><area href="arealink" /></div> TC2: <div class="h-x"><a class="u-x" href="alink"></a><area href="arealink" /></div>
  63. # [01:15] <@tantek> real world <area> handling in general is something we need to / are re-assessing
  64. # [01:15] <Calli> ok
  65. # [01:15] <@tantek> there are use-cases for capturing the shapes of areas
  66. # [01:15] <@tantek> e.g. photo notes
  67. # [01:16] <@tantek> but we haven't quite figured out a good way of doing so
  68. # [01:16] <@tantek> we tried one way, but found it didn't work in the micropub serialization scenario
  69. # [01:16] <@tantek> so it is again an unsolved problem
  70. # [01:17] <@tantek> Calli - if you have real world examples of <area> usage with microformats, or even real world examples of <area> usage that could *benefit* with addition of microformats, please provide the URLs as those would provide excellent emprical data to shape proposed solutions
  71. # [01:18] <Calli> I don't have any uses for area for my interests, I picked a test with A and AREA because of how the spec deals with only-of-type - needed an element that could be used forimplied URL prop that wasn't of the same type as A
  72. # [01:20] <kevinmarks> the implied name there is from hfeed not h-feed
  73. # [01:20] <kevinmarks> so that is a 1->2 mapping bug
  74. # [01:21] <kevinmarks> the https://blog.roku.com/blog/2015/11/23/black-friday-deals-sneak-peek-roku-se-roku-3-roku-streaming-stick-tcl-roku-tv/ example
  75. # [01:23] * Quits: Calli (6ca2f57e@gateway/web/freenode/ip.108.162.245.126) (Ping timeout: 252 seconds)
  76. # [01:23] * Joins: gordonb (~gordonb@67-131-47-154.dia.static.qwest.net)
  77. # [01:45] * Joins: Calli (6ca2f549@gateway/web/freenode/ip.108.162.245.73)
  78. # [01:45] <Calli> oh right - yeah parser bug then
  79. # [01:46] <Calli> so i guess I don't know if I'll encounter h-feeds without names in the wild, but if I do...
  80. # [01:46] <Loqi> [[microformats2-parsing-issues]] http://microformats.org/wiki/index.php?title=microformats2-parsing-issues&diff=65335&oldid=65334&rcid=101724 * Kylewm * (+790) /* implied properties when an explicit class is provided */ suggestion: split these out per property. I suspect it only affects u-url.
  81. # [01:47] <kevinmarks> I wonder if implied name should include children or not
  82. # [01:47] <kevinmarks> tricky as with h-feed you probably don't want that, but with h-review of an h-card, you may
  83. # [01:48] <Loqi> [[microformats2-parsing-issues]] http://microformats.org/wiki/index.php?title=microformats2-parsing-issues&diff=65336&oldid=65335&rcid=101725 * Kylewm * (-5) /* implied properties when an explicit class is provided */ simplify suggested modification to implied url prasing
  84. # [01:50] <@tantek> oh hey welcome back Loqi wiki diffs!
  85. # [01:50] * Loqi grins profusely
  86. # [01:50] <@tantek> kevinmarks - yes, due to nested h-card or other structures, you do want that
  87. # [02:17] * Quits: gordonb (~gordonb@67-131-47-154.dia.static.qwest.net) (Quit: gordonb)
  88. # [02:38] * Joins: gordonb (~gordonb@174-21-90-208.tukw.qwest.net)
  89. # [02:43] * Quits: gordonb (~gordonb@174-21-90-208.tukw.qwest.net) (Client Quit)
  90. # [03:00] * Quits: Calli (6ca2f549@gateway/web/freenode/ip.108.162.245.73) (Quit: Page closed)
  91. # [03:00] * Joins: Calli (6ca2f576@gateway/web/freenode/ip.108.162.245.118)
  92. # [03:08] <Calli> kylewm makes good points about name and photo in his edit (namely that suggested changes won't really affect name because of the fallback to textContent and changes are possibly counterproductive for photo where it feels like presence of an image even if it's marked with another property is still strong enough evidence that the image is appropriate for the implied photo property)
  93. # [03:09] <@tantek> yes that does seem sensible
  94. # [03:09] <@tantek> I wonder if it is too much "smarts"
  95. # [03:09] <@tantek> and will make it feel unpredictable
  96. # [03:09] <Calli> which leaves just implied URL
  97. # [03:09] <@tantek> that's my only concern
  98. # [03:09] <@tantek> but it is only a soft concern, I can be swayed
  99. # [03:09] <Calli> which then makes me think that for simplicity sticking with existing spec is good enough
  100. # [03:10] <Calli> Is it better to provide an incorrect URL or no URL at all? How would an author detect either case? Do any of the parsers focus on authoring scenarios? Do any of them highlight implied properties or missing properties?
  101. # [03:11] <Calli> So having considered it, I think I'm in the camp of leave the spec as it is
  102. # [03:15] <@tantek> bad data is worse than no data
  103. # [03:16] <@tantek> so incorrect URL is worse than no URL
  104. # [03:16] <@tantek> in general
  105. # [03:16] <@tantek> ok interesting
  106. # [03:16] <@tantek> (re: camp of leaving spec as is)
  107. # [03:16] <@tantek> that's very useful to know - please feel encouraged to note that in the issue!
  108. # [03:16] <Calli> I agree - but then my solution would be not to imply URL (or name or photo)
  109. # [03:19] <Calli> Seems like you're concerned with the authoring side of things and that's why you've gone for implied properties right? But how would an author be made aware that either they are missing a value for URL where it might be expected or they are getting a value that they might not expect?
  110. # [03:20] <@tantek> all valid questions
  111. # [03:21] <@tantek> that is one of the reasons that I proposed the relatively simple rule of - if the author has specified a u-* property on an element, then no other u-* properties are implied.
  112. # [03:22] <@tantek> same with if the author has specified a p-* property, then no p-* properties are implied
  113. # [03:22] <@tantek> on that element
  114. # [03:22] <@tantek> that is a pretty simple rule to remember
  115. # [03:22] <@tantek> by specifying properties on an element, you as an author signal that you want that element to mean/do precisely *this* (whatever those properties are), and *nothing* else.
  116. # [03:23] <Calli> yeah - that is a good rule.
  117. # [03:23] <@tantek> the cross-interaction of "if you specify a p-* property then no u-* props are implied" and "if you specify a u-* property then no p-* properties are implied" works via a different simplification
  118. # [03:23] <kevinmarks> that is a good rule
  119. # [03:23] <@tantek> that is
  120. # [03:24] <kevinmarks> the nesting issue is trickier
  121. # [03:24] <@tantek> by specifying *any* property on an element, you as an author signal that you want that element to mean/do precisely *this* (whatever those properties are), and *nothing* else.
  122. # [03:24] <@tantek> hence why the two proposals are listed there
  123. # [03:24] <@tantek> in the issue
  124. # [03:24] <@tantek> I wanted feedback / input on both
  125. # [03:25] <@tantek> both are relatively simple rules, but different enough that to "new eyes" one may appear better than the other
  126. # [03:25] <@tantek> thus really interested in seeing recorded feedback on both
  127. # [03:25] <@tantek> thank you Calli kevinmarks !
  128. # [03:31] <Calli> On a related note: When considering parsing spec changes, do you (the community) have a large body of MF2 data that you don't want to change the meaning of? Or are changes still acceptable? If you're trying to avoid radical reinterpretations of existing data, do you have a crawler or some other means of getting hold of it?
  129. # [03:34] <@tantek> we haven't gotten quite to that point yet - though there is a growing amount of indieweb data based on mf2
  130. # [03:37] * Quits: Calli (6ca2f576@gateway/web/freenode/ip.108.162.245.118) (Ping timeout: 252 seconds)
  131. # [03:45] * Quits: @tantek (~tantek@guest-nat.p2p.sfo1.mozilla.com) (Quit: tantek)
  132. # [03:54] * Joins: Calli (6ca2f556@gateway/web/freenode/ip.108.162.245.86)
  133. # [04:06] <Calli> More random thoughts about implied properties: Why doesn't implied name generate text content like an explicit p- property (which does converts imgs to their alt/src attributes insertion)? Is that difference intentional?
  134. # [04:06] <Loqi> [@fjdekermadec] Nobody cares, but I finally implemented #microformats on the sites of all our clients. 2010 @Google called and they want their index back! (http://twtr.io/16d5Thkm3JQ)
  135. # [04:15] * Quits: KartikPrabhu (~kartik@2602:306:3859:10e0:8dca:e7a8:ce0f:5b0f) (Ping timeout: 250 seconds)
  136. # [04:20] * Joins: KartikPrabhu (~kartik@2602:306:3859:10e0:b513:3974:589b:8652)
  137. # [04:26] * Quits: Calli (6ca2f556@gateway/web/freenode/ip.108.162.245.86) (Ping timeout: 252 seconds)
  138. # [04:33] * Joins: tantek (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com)
  139. # [04:33] * ChanServ sets mode: +o tantek
  140. # [04:35] <kevinmarks> the large body is probably in brid.gy/webmention.*
  141. # [04:49] * Quits: @tantek (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com) (Ping timeout: 245 seconds)
  142. # [04:50] * Joins: andicascadesf (~andicasca@104-244-27-188.PUBLIC.monkeybrains.net)
  143. # [05:18] * Quits: andicascadesf (~andicasca@104-244-27-188.PUBLIC.monkeybrains.net) (Quit: andicascadesf)
  144. # [05:42] * Quits: TallTed (~Thud@c-98-216-254-6.hsd1.ma.comcast.net)
  145. # [05:47] * Joins: tantek (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com)
  146. # [05:47] * ChanServ sets mode: +o tantek
  147. # [07:11] * Joins: andicascadesf (~andicasca@104-244-27-188.PUBLIC.monkeybrains.net)
  148. # [07:43] * Quits: andicascadesf (~andicasca@104-244-27-188.PUBLIC.monkeybrains.net) (Quit: andicascadesf)
  149. # [07:44] * Joins: andicascadesf (~andicasca@104-244-27-188.PUBLIC.monkeybrains.net)
  150. # [07:44] * Quits: andicascadesf (~andicasca@104-244-27-188.PUBLIC.monkeybrains.net) (Client Quit)
  151. # [08:09] * Quits: @tantek (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
  152. # [08:46] * Joins: KartikPrabhu1 (~kartik@2602:306:3859:10e0:9cd5:8c7c:91a9:42cd)
  153. # [08:48] * Quits: KartikPrabhu (~kartik@2602:306:3859:10e0:b513:3974:589b:8652) (Ping timeout: 250 seconds)
  154. # [09:07] * Joins: nitot (~nitot@210.209.24.109.rev.sfr.net)
  155. # [09:18] * Joins: tantek (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com)
  156. # [09:18] * ChanServ sets mode: +o tantek
  157. # [09:22] * Quits: nitot (~nitot@210.209.24.109.rev.sfr.net) (Remote host closed the connection)
  158. # [09:37] * Quits: @tantek (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com) (Read error: Connection reset by peer)
  159. # [09:38] * Joins: tantek_ (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com)
  160. # [09:38] * ChanServ sets mode: +o tantek_
  161. # [09:43] * Quits: @tantek_ (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com) (Ping timeout: 250 seconds)
  162. # [09:50] * Quits: gRegorLove (~me@c-73-140-189-21.hsd1.wa.comcast.net) (Ping timeout: 250 seconds)
  163. # [11:04] * Joins: adactio (~adactio@212.42.170.121)
  164. # [11:04] * ChanServ sets mode: +o adactio
  165. # [11:48] * Joins: andicascadesf (~andicasca@104-244-27-188.PUBLIC.monkeybrains.net)
  166. # [12:38] * Quits: KartikPrabhu1 (~kartik@2602:306:3859:10e0:9cd5:8c7c:91a9:42cd) (Ping timeout: 250 seconds)
  167. # [12:41] * Joins: KartikPrabhu (~kartik@2602:306:3859:10e0:9cd5:8c7c:91a9:42cd)
  168. # [13:35] * Quits: Erkan_Yilmaz (~Erkan_Yil@wikimedia/Erkan-Yilmaz) (Read error: Connection reset by peer)
  169. # [13:51] * Quits: andicascadesf (~andicasca@104-244-27-188.PUBLIC.monkeybrains.net) (Quit: andicascadesf)
  170. # [13:59] * Joins: Erkan_Yilmaz (~Erkan_Yil@dslb-088-066-047-111.088.066.pools.vodafone-ip.de)
  171. # [13:59] * Quits: Erkan_Yilmaz (~Erkan_Yil@dslb-088-066-047-111.088.066.pools.vodafone-ip.de) (Changing host)
  172. # [13:59] * Joins: Erkan_Yilmaz (~Erkan_Yil@wikimedia/Erkan-Yilmaz)
  173. # [14:19] * Joins: eschnou (~eschnou@2a02:a03f:8f3:8500:f24d:a2ff:fe83:4117)
  174. # [14:50] * Quits: KartikPrabhu (~kartik@2602:306:3859:10e0:9cd5:8c7c:91a9:42cd) (Ping timeout: 250 seconds)
  175. # [15:15] * Quits: Left_Turn (~Left_Turn@unaffiliated/turn-left/x-3739067) (Ping timeout: 245 seconds)
  176. # [15:52] * Joins: TallTed (~Thud@c-98-216-254-6.hsd1.ma.comcast.net)
  177. # [15:58] * Quits: @adactio (~adactio@212.42.170.121) (Ping timeout: 260 seconds)
  178. # [16:35] * Quits: MeanderingCode (~Meanderin@45.55.58.9) (Remote host closed the connection)
  179. # [16:37] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  180. # [16:37] * ChanServ sets mode: +o KevinMarks_
  181. # [16:40] * Joins: MeanderingCode (~Meanderin@palantir.aetherislands.net)
  182. # [16:41] * Joins: nitot (~nitot@183-97-190-109.dsl.ovh.fr)
  183. # [16:42] * Quits: kevinmarks (~kevinmark@67.164.14.200) (Ping timeout: 260 seconds)
  184. # [16:43] * Joins: KevinMarks (~yaaic@2607:fb90:426:78bb:f5e0:2b3b:5afd:3ea3)
  185. # [16:43] * ChanServ sets mode: +o KevinMarks
  186. # [16:46] * Quits: @KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
  187. # [16:59] * Quits: eschnou (~eschnou@2a02:a03f:8f3:8500:f24d:a2ff:fe83:4117) (Ping timeout: 264 seconds)
  188. # [17:11] * Joins: Left_Turn (~Left_Turn@unaffiliated/turn-left/x-3739067)
  189. # [17:39] * Quits: @KevinMarks (~yaaic@2607:fb90:426:78bb:f5e0:2b3b:5afd:3ea3) (Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org)
  190. # [17:40] * Joins: KevinMarks (~yaaic@2607:fb90:426:78bb:f5e0:2b3b:5afd:3ea3)
  191. # [17:40] * ChanServ sets mode: +o KevinMarks
  192. # [17:45] * Joins: tantek (~tantek@guest-nat.p2p.sfo1.mozilla.com)
  193. # [17:45] * ChanServ sets mode: +o tantek
  194. # [17:51] * Joins: kevinmarks_ (~kevinmark@172.56.38.244)
  195. # [17:57] * Joins: gRegorLove (~me@c-73-140-189-21.hsd1.wa.comcast.net)
  196. # [18:41] * Quits: nitot (~nitot@183-97-190-109.dsl.ovh.fr) (Remote host closed the connection)
  197. # [18:58] * Joins: Calli (32f5823b@gateway/web/freenode/ip.50.245.130.59)
  198. # [19:01] * Quits: kevinmarks_ (~kevinmark@172.56.38.244) (Ping timeout: 245 seconds)
  199. # [19:18] * Joins: kevinmarks_ (~kevinmark@2620:101:80fb:232:d930:81ff:db16:2992)
  200. # [19:48] * Quits: Calli (32f5823b@gateway/web/freenode/ip.50.245.130.59) (Ping timeout: 252 seconds)
  201. # [20:06] * Joins: KevinMarks__ (~yaaic@2620:101:80fb:232:81d8:ae2e:e99e:d14a)
  202. # [20:06] * ChanServ sets mode: +o KevinMarks__
  203. # [20:09] * Quits: @KevinMarks (~yaaic@2607:fb90:426:78bb:f5e0:2b3b:5afd:3ea3) (Ping timeout: 260 seconds)
  204. # [20:28] * Joins: eschnou (~eschnou@192.55-247-81.adsl-dyn.isp.belgacom.be)
  205. # [22:49] * Quits: kevinmarks_ (~kevinmark@2620:101:80fb:232:d930:81ff:db16:2992) (Remote host closed the connection)
  206. # [22:53] * Quits: eschnou (~eschnou@192.55-247-81.adsl-dyn.isp.belgacom.be) (Ping timeout: 260 seconds)
  207. # [22:54] * Joins: kevinmarks (~kevinmark@2620:101:80fb:232:d930:81ff:db16:2992)
  208. # Session Close: Wed Dec 02 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