XMPP Council - 2013-02-20


  1. Tobias has left

  2. m&m has joined

  3. bear has left

  4. bear has joined

  5. bear has left

  6. m&m has left

  7. Tobias has joined

  8. Tobias has left

  9. Tobias has joined

  10. Tobias has left

  11. Tobias has joined

  12. Tobias has left

  13. Tobias has joined

  14. Tobias has left

  15. Zash has joined

  16. Tobias has joined

  17. Kev has left

  18. Zash has left

  19. Zash has joined

  20. Zash has left

  21. Zash has joined

  22. m&m has joined

  23. Zash has joined

  24. ralphm has joined

  25. Tobias

    when should one use a stream-feature and what are the alternatives?

  26. Zash

    Features related to the stream itself?

  27. Lance has joined

  28. Tobias

    the delayed delivery case Lance mentioned yesterday...i.e. having 200 users on your roster, and receiving 200 offline presences with delayed delivery, so you know when they went offline could be quite a bit of traffic

  29. Tobias

    heh

  30. Kev

    That doesn't happen until you send your initial presence.

  31. Tobias

    right

  32. Kev

    So it doesn't seem that it needs a stream feature to stop it.

  33. Tobias

    so it could be in caps?

  34. Tobias

    s/caps/disco?

  35. bear has joined

  36. Kev

    Could be in caps, even, yes.

  37. Tobias

    hmm....

  38. Kev

    Although you'd get the presence if they were online, so ... :)

  39. Tobias

    hmm...

  40. Tobias

    or could stanza filtering filter that out

  41. Tobias

    didn't we have a XEP for that?

  42. Zash

    SIFT

  43. Tobias

    could it filter delayed delivery out of presence stanzas?

  44. m&m

    SIFT didn't get that specific, but it is extensible

  45. m&m

    meaning, you can add new conditions

  46. Zash

    Tobias: Some servers already send unavailable presence

  47. Zash

    So that traffic already exists.

  48. Kev

    Right.

  49. Tobias

    so nothing we can do about it?

  50. ralphm

    Cry?

  51. m&m

    from a server to the client, SIFT (possibly with a special extension) should be able to do what you want

  52. ralphm

    but what m&m says

  53. m&m

    the trick is to get servers to implement it (-:

  54. Zash

    Someone argued that it made sense to drop such unavailable presence

  55. m&m

    I bet MattJ will have it done in prosody by lunch tomorrow if you asked nicely

  56. Zash

    m&m: Wait, for what?

  57. m&m

    (-:

  58. ralphm

    is MattJ up and running again?

  59. m&m

    for the "SIFT-unavailable-with-delay"

  60. Zash

    Ah

  61. Zash

    I wrote a plugin yesterday to filter out unavailable in response to probes if it had no childs

  62. Kev

    And ding ding ding.

  63. ralphm

    Zash: what is the exact issue with the offline presences

  64. Kev

    1) Roll call

  65. Kev

    I'm here!

  66. ralphm

    Zash: after the meeting

  67. m&m

    presente

  68. ralphm

    I'm here

  69. Tobias

    same here

  70. Kev

    And I'm assuming we have continued apologies from MattJ until we hear otherwise.

  71. Zash

    He said he was going to be here

  72. ralphm

    anyone know how is these days?

  73. Kev

    Zash: Ah, OK. Maybe he will.

  74. Kev

    ralphm: I've not spoken to him at all.

  75. Kev

    I'd worry, but he got word through to Peter that he'd be offline, so I just hope he gets fixed soon.

  76. Kev

    Aaaaanyway.

  77. MattJ has joined

  78. m&m notes stpeter just walked into the office

  79. Kev

    2) Peter'd like to issue an LC on 152 (Reachability Addresses)

  80. Kev

    MattJ: Welcome back.

  81. m&m

    normally I'd be +1 on LC

  82. MattJ

    Hey :)

  83. Kev

    m&m: There's a "but"

  84. MattJ

    Never gladder to attend a meeting before

  85. m&m

    IETF is kicking my butt

  86. ralphm

    MattJ: WB!

  87. m&m

    and the meeting hasn't even happened yet!

  88. m&m

    I and stpeter might be the only ones in this predicament

  89. ralphm

    IETF doesn't want to be reachable/

  90. ralphm

    ?

  91. m&m

    ralphm: opposite problem, it's too reachable

  92. Kev

    m&m:So you'd like to delay the LC on 152 until after the IETF meeting?

  93. m&m

    anyway, I've no objections to LC, but I would like to extend the deadline by a couple of weeks

  94. ralphm

    sure thing

  95. m&m

    Kev: or that

  96. Kev

    A one-month LC, then?

  97. ralphm

    Long Call

  98. ralphm

    I am up for that

  99. Kev

    LCLC

  100. Kev

    Or LC^2.

  101. m&m

    either works for me, although delaying would probably work out better for my inbox (-:

  102. Zash

    L²C

  103. m&m

    heh

  104. m&m

    Zash wins

  105. Kev

    Congratulations.

  106. Zash

    \o/

  107. Kev

    MattJ: Opinion?

  108. MattJ

    I have some catching up to do

  109. waqas has joined

  110. Tobias

    later or longer last call are either fine with me

  111. MattJ

    Longer LCs are fine by me in general

  112. stpeter has joined

  113. m&m

    as long as we remember the deadline

  114. stpeter

    oops :-)

  115. MattJ

    We've had to extend LCs multiple times in the past

  116. m&m

    which reminds me, I have some BOSH patches to submit

  117. Kev

    I trust Peter to remember the deadline :D

  118. stpeter

    MattJ!!!

  119. ralphm

    ā˜Ž

  120. Tobias

    that's what we have a calendar for, not?

  121. MattJ

    stpeter!!

  122. stpeter

    ralphm: :-)

  123. m&m

    Tobias!!!

  124. stpeter checks http://logs.xmpp.org/council/130220/

  125. Kanchil

    stpeter: http://logs.xmpp.org/council/130220/: Chatroom logs for council@muc.xmpp.org (Wednesday, February 20, 2013)

  126. Kev

    MattJ: Are you OK with an LC on this one?

  127. MattJ

    +1

  128. Kev

    Excellent.

  129. Kev

    3) Date of next meeting?

  130. Kev

    SBTSBC?

  131. Tobias

    wfm

  132. m&m

    yes, as long as we keep extending the deadlines (-:

  133. ralphm

    šŸ‘

  134. Kev

    ralphm: I'm going to assume that's the special unicode glyph pair for "works for me" :)

  135. stpeter

    y'know, XEP-0152 has been sitting around for a long time, so there's no big hurry about a Last Call, although it would be nice to advance it before draft-ivov-xmpp-cusax becomes an RFC

  136. ralphm

    THUMBS UP SIGN (U+1F44D)

  137. m&m

    oh, unicode

  138. Kev

    Was it? o_O

  139. Kev

    Oh, yes, that's very different.

  140. Kev

    In the font Swift uses it looked like a left sleeve and a right sleeve.

  141. Kev

    Anyway.

  142. Kev

    4) Any other business

  143. Kev

    I think Peter'd like to ask us to go look at WG stuff.

  144. Kev

    (Precis)

  145. stpeter

    right :-)

  146. m&m

    Yes. When can we advance āˆ’308 to draft?

  147. Kev

    Yeah, Gunnar was chasing me about that the other day (in a mail that went straight to spam, bad dog Gmail).

  148. m&m

    heh

  149. Tobias

    here....everybody roughly okay with the direction my XEP-0012 deprecation work is heading in? new experimental XEP for idle, new informational XEP for presence+delayed delivery for last presence change time.

  150. ralphm

    Kev: it is not a glyph pair?

  151. m&m

    Tobias: tentatively

  152. Kev

    I'll try desperately to address LC feedback as soon as I've got a spare cycle.

  153. m&m

    /nod

  154. m&m

    I

  155. stpeter

    Tobias: yes, that seems fine, but I need to look at it in detail still (next week)

  156. m&m

    gah

  157. ralphm

    what stpeter says

  158. m&m

    I've got internal teams asking about the status

  159. m&m

    of 308

  160. stpeter

    :-)

  161. Kev

    Tobias: It needs something for uptime, too. That one's widely deployed, and is even used. Although I'd rather something better :)

  162. Tobias

    Kev, yeah...directed presence probes to hosts with delayed delivery response :)

  163. Zash

    available presence + delayed?

  164. Tobias

    i'll mention it in the informational XEP

  165. Kev

    m&m: Words fail to describe how many balls I'm trying to juggle at the moment, but I will try to add that one as well. And watch it all come crashing down.

  166. m&m

    Kev: I feel your pain

  167. Kev

    Any other any other business?

  168. stpeter

    Kev: need co-authors?

  169. Kev

    stpeter: I think I just need a few hours.

  170. Kev

    stpeter: Or a time machine.

  171. stpeter

    Kev: which you don't have!

  172. Kev

    I'll get to it. Maybe I'll have some minutes watching films with Cath at the weekend or something.

  173. stpeter

    :/

  174. stpeter

    ok

  175. stpeter

    for Kev's sake, I think we're done

  176. m&m

    /nod

  177. Tobias

    yup

  178. Kev

    i have nothing else, at least.

  179. Kev

    Right.

  180. Kev

    Thanks all.

  181. Kev bangs the gavel.

  182. m&m goes to talk to stpeter about DNA

  183. stpeter

    yay :-)

  184. Zash

    so

  185. Kev

    Deoxyribonucleic acid? :)

  186. Zash

    ralphm: Offline presence in response to probes are redundant, unless they carry some kind of extended data, like delayed delivery.

  187. m&m

    Kev: very close. Domain Name Associations (or Assertions)

  188. stpeter

    draft-saintandre-xmpp-dna

  189. Kev

    Yes, I knew.

  190. Kev

    Really.

  191. m&m

    (-:

  192. ralphm

    Zash: arguably they also tell you that you still have a presence subscription and that the remote host is reachable.

  193. Zash

    ralphm: Right. Otoh it's traffic you may or may not want. The person who wanted this filter works on a mobile client

  194. ralphm

    so, for a mobile client, I can think of two considerations

  195. bear has left

  196. ralphm

    1) battery, 2) bandwidth

  197. ralphm

    For case 1) I'd argue that it is very likely that your antenna is in fully up mode when you receive it.

  198. ralphm

    For case 2) I'm pretty sure it compresses quite well

  199. Kev

    And for (1) you want something like google:queue.

  200. Zash

    If the remote host isn't reachable then you will get an error. If you no longer have a subscription you would get a unsubscibe(d) reply, no?

  201. ralphm

    (playing devil's advocate)

  202. ralphm

    Zash: *maybe*

  203. Kev

    Zash: Yes.

  204. Kev

    Well, you needn't get an error.

  205. Kev

    You will get unsubscribed for no longer having a sub.

  206. ralphm

    Not for 3921 implementations

  207. Kev

    That's true.

  208. Zash

    Oh

  209. ralphm

    So, as I said, arguably they do carry information.

  210. ralphm

    Which doesn't invalidate your case

  211. ralphm

    but we should do google-queue/SIFT

  212. Zash

    google-queue was the thing where it queued up "less important" stanzas, like presence until something more important like a chat message or iq came in?

  213. Lance

    ralphm a 3) issue is the effect on startup time for the app, which IIRC was the issue raised by the mobile developer

  214. Kev

    Zash: Yes.

  215. Kev

    Lance: It shouldn't affect startup time for the app. It's all async.

  216. Kev

    Not other than is covered by (2) anyway.

  217. Zash

    If s2s setup for sending probes takes a long time, it might even lower the radio state before it gets replies

  218. ralphm

    Zash: hence google-queue

  219. Zash

    Yes

  220. ralphm

    you wouldn't get those until you'd send something or receive a normal message

  221. ralphm

    I don't really believe in 3) for properly designed applications

  222. Kev

    Saying that.

  223. Kev

    This really does hurt clients.

  224. Kev

    That's why the stpeter roster test is nasty.

  225. ralphm

    Kev: so is that because of badly written clients or the shear amount of data that has to be sifted through?

  226. ralphm

    (genuinly curious)

  227. Kev

    ralphm: I spent a very long time profiling and tuning Swift for this - it's the roster updates.

  228. Kev

    The roster's sorted and every time you get a new presence that may potentially update the roster order.

  229. ralphm

    oh, hmm

  230. ralphm

    how did you resolve that? delayed updating the roster order?

  231. Kev

    So you've got the pain of doing a lookup across the entire roster for the right JID to update, in all the right groups, then the pain of calculating the new presence to render (actually insignificant usually) and then the pain of reordering the widget.

  232. Kev

    No, just fiddling with data structures.

  233. Kev

    Maps instead of vectors for finding the JID in the roster makes a hell of a difference.

  234. Kev

    I got the stpeter test down below 10 seconds for Swift - I think the next best client at the time was Psi with about a minute.

  235. Kev

    Modern hardware will obviously improve this dramatically.

  236. ralphm

    so but in this case, we are talking about unavailable presence

  237. ralphm

    that wouldn't affect anything in the roster

  238. Kev

    It does, somewhat.

  239. Kev

    It doesn't cause a redraw (unless you have a status as well).

  240. Kev

    But it does need you to do all of the data structure walking to find that it doesn't cause an update.

  241. Lance

    kind of. because its FIFO, if you have a large roster and lots of unavailable, the app appears to be much laggier than it really is on startup

  242. ralphm

    But did you really do a redraw for every presence? One of the first things I'd try is delaying it by, maybe, a second?

  243. Kev

    I just update the model, and let Qt manage when the redraws happen.

  244. ralphm

    Kev: sure, but I assume you can batch that, too

  245. Kev

    It wasn't paint calls themselves that were appearing in the profiling, at the point that I stopped work on it.

  246. Kev

    I'm sure one could squeeze yet more out of it - being around an order of magnitude faster than anyone else was enough for me at the time :)

  247. ralphm

    hah

  248. Ge0rG has joined

  249. Lance

    and here's the one behind the issue. hey Ge0rG

  250. Ge0rG

    hi! I'm Georg from yaxim.org

  251. ralphm

    but, still, if you also control the server side (the one the client is connecting too), don't we have something like quickstart for non-BOSH connections?

  252. ralphm

    hah, that's funny. I was just thinking about how yaxim also doesn't seem to like large rosters :-)

  253. Zash

    ralphm: This is the guy

  254. Ge0rG

    there is roster versioning, which reduces the overhead; but it only eliminates half of the traffic when connecting

  255. ralphm

    Zash: awesome. We are full circle.

  256. Ge0rG

    delaying UI/storage updates on incoming presences is only a mitigation measure... the incoming traffic still remains

  257. xnyhps has joined

  258. bear has joined

  259. ralphm

    Ge0rG: I was just trying out yaxim the other day. It does indeed seem to have issues with my roster. xabber seems to have less problems with it (no offence, also, it has other problems)

  260. Kev

    ralphm: What's your largest roster group, and how many do you have?

  261. Ge0rG

    ralphm: yaxim is storing roster+presences in sqlite, with ca. 100ms of writing time for every. single. item.

  262. Kev

    That sounds like a good thing to not do, then :)

  263. ralphm

    27 roster groups totalling 343 contacts. The largest one is 45

  264. Kev

    ralphm: That sounds sufficiently small that it shouldn't cause too many issues.

  265. ralphm

    Kev: right

  266. Ge0rG

    yes, I am currently preparing a huge rework of the backend; but it will take time

  267. Kev

    Same order of magnitude as my roster (although larger).

  268. ralphm

    Kev: so I assume Ge0rG has some work cut out for him

  269. Ge0rG

    and I do not really see a reason in delivering bare-jid unavailable presences (as unavialable is probably the default state anyway)

  270. ralphm

    nevertheless, something like XEP-0305 might also be useful for our TCP binding

  271. ralphm

    Ge0rG: http://logs.xmpp.org/council/130220/

  272. Kanchil

    ralphm: http://logs.xmpp.org/council/130220/: Chatroom logs for council@muc.xmpp.org (Wednesday, February 20, 2013)

  273. ralphm

    Ge0rG: we did some talking about it before you joined

  274. Kev

    ralphm: I think 305 doesn't help at all here, actually.

  275. Ge0rG

    198 would help...

  276. Ge0rG

    provided you had a session before

  277. Kev

    Right.

  278. ralphm

    Kev: I'm sorry, I meant 198 of course

  279. Kev

    Right, 198's fine as long as you have an existing session.

  280. Kev

    But for initial login you don't.

  281. Ge0rG

    but not for initial connection, or if you have been offline for a longer time (5 or 30mins in prosody?)

  282. Zash

    Ge0rG: Configurable, defaults to something like 5min

  283. ralphm

    but you can throw away the unavailables right after having parsed them

  284. Zash

    It would be nice to have some way to suspend a session so it wouldn't timeout

  285. Kev

    ralphm: No, you can't.

  286. ralphm

    Kev: if he thinks they are useless you can

  287. Kev

    ralphm: Right, but you can't know they're useless until after you've checked against the roster.

  288. Ge0rG

    ralphm: for that you need to check the previous state of the JID

  289. Kev

    Although if sqlite is the bottleneck here, you can certainly easily bin them before that.

  290. ralphm

    Kev: that was my point

  291. Ge0rG

    also, not everybody can use tls/stream compression, and data traffic is not free everywhere in the world

  292. ralphm

    well, ehm

  293. Kev

    Ah, that's interesting.

  294. Kev

    Why would you not be able to use stream compression?

  295. Ge0rG

    so what is the additional information carried by presence-unavailable from bare JIDs in 3921 implementations?

  296. Kev

    Ge0rG: Nothing, but 3921's obsoleted now.

  297. ralphm

    it is actually likely they wouldn't send them

  298. Kev

    Or, well, sometimes nothing, depending whether there was a <status/> there

  299. Ge0rG

    ralphm mentioned 3921 as part of the pro-transmitting argument

  300. ralphm

    Ge0rG: I did

  301. ralphm

    Ge0rG: the point is that you can't know

  302. Ge0rG

    which I am trying to understand now

  303. Ge0rG

    Kev: stream compression is buggy in certain client-server combinations (I blame openfire, but not enough datapoints yet)

  304. Kev

    Ah.

  305. ralphm

    Ge0rG: some implementations will not send them, some will send unsubscribe (and some not) and some will send an error (or not)

  306. Ge0rG

    Kev: https://github.com/pfleidi/yaxim/issues/85

  307. Kev

    Yes, indeed, I remember something about OpenFire's compression stuff being broken.

  308. ralphm

    do blame openfire

  309. ralphm

    :-)

  310. Ge0rG

    but blaming openfire will not fix the real-world problem for my users

  311. Kev

    Ge0rG: No, indeed.

  312. Ge0rG

    and they will blame yaxim instead

  313. ralphm

    and if they get around fixing stuff, also let them fix the thing where you have to send presence to receive iq's and messages to a full resource

  314. Ge0rG

    ralphm: if old implementations are not guaranteed to send anything, why would we demand new implementations to send a presence-unavailable?

  315. Zash

    There is no demand

  316. Kev

    We don't, do we?

  317. ralphm

    We don't

  318. Zash

    It's a SHOULD

  319. ralphm

    we allow it

  320. Kev

    Zash: Ah, is it?

  321. Kev

    That's domanding it, then.

  322. Ge0rG

    thats why I am asking

  323. ralphm

    Unfortunately I have to go for dinner

  324. Zash

    Kev: It is?

  325. Ge0rG

    so my suggestion would be to change it into a SHOULD NOT :P

  326. ralphm

    this will not help your case

  327. ralphm

    at least not very soon

  328. Kev

    It's not true, though, that an unavailable contains no extra information. It does - it tells you that you know the state of the remote user.

  329. Ge0rG

    ok, actually it needs some more context explanation

  330. Kev

    Until you receive your first presence from them you've no idea if they're online or offline.

  331. Ge0rG

    Kev: but you should assume the remote user is unavailable by default...

  332. Ge0rG

    or there should be yet another presence state "unknown"

  333. Zash

    The behaviour where the server tries to keep a consistent view of the availability of contacts at all times would help this

  334. Zash

    was it Dave who wrote about that?

  335. Ge0rG

    [offtopic] is there an (http) API to look up the XEP name given the number?

  336. Zash

    Ge0rG: Sorta

  337. Zash

    There's an XML file

  338. Kev

    !xep 198

  339. Kanchil

    Kev: XEP-0198(sm): http://xmpp.org/extensions/xep-0198.html Stream Management - Standards Track/Draft - Updated: 2011-06-29

  340. Zash

    Ge0rG: Or, if you know the number, just stick it into that url

  341. Ge0rG

    Zash: I want name and number, for a jekyll plugin

  342. Ge0rG

    you know, if you are doing something, do it right the first time :)

  343. Zash

    Ge0rG: http://xmpp.org/extensions/xeps.xml

  344. Ge0rG

    cool, thanks

  345. Zash

    http://web.archive.org/web/20120208104426/http://blog.dave.cridland.net/?p=144

  346. Kanchil

    Zash: http://web.archive.org/web/20120208104426/http://blog.dave.cridland.net/?p=144: Advice to Santa on fast presence delivery &#8211; text/plain

  347. Kev

    FWIW, when talking about 'doing it right first time', having played with both jekyll and nanoc, I prefer nanoc.

  348. Ge0rG

    I'm not going to jump trains again ;)

  349. Kev

    Fair enough.

  350. Kev

    I did, FWIW.

  351. Kev

    (Wordpress->jekyll->nanoc)

  352. Ge0rG

    I's been only two weeks since I set up http://yaxim.org/

  353. Kanchil

    Ge0rG: http://yaxim.org/: yaxim - yaxim

  354. Ge0rG

    and it is good enough

  355. Kev

    OK.

  356. Kev

    Ah, maybe octopress makes things less bad.

  357. nulani has joined

  358. Lance has left

  359. Tobias has joined

  360. Neustradamus has joined

  361. nulani has left

  362. xnyhps has left

  363. xnyhps has joined

  364. stpeter has left

  365. ralphm has left

  366. ralphm has joined

  367. Neustradamus has joined

  368. Neustradamus has joined

  369. ralphm

    bye, again, jabber.org

  370. ralphm

    :-/

  371. xnyhps has left

  372. stpeter has joined

  373. xnyhps has joined

  374. ralphm has left

  375. ralphm has joined

  376. Kev

    That one was my fault.

  377. Kev

    I did a stupid.

  378. ralphm

    Kev: don't do stupids

  379. Kev

    Excellent advice.

  380. Kev

    I cannot fault it.

  381. ralphm

    I am also not sure it is all right now

  382. ralphm

    I cannot join a MUC at conference.ik.nu from jabber.org

  383. Tobias has joined

  384. Tobias has joined

  385. stpeter has left

  386. Neustradamus has joined

  387. ralphm has left

  388. ralphm has joined

  389. Tobias has left

  390. m&m has left

  391. Tobias has joined

  392. waqas has left

  393. Tobias has left

  394. Tobias has joined