XMPP Council - 2013-02-20

00:39:10 Tobias has left
01:02:15 m&m has joined
02:10:41 bear has left
04:20:16 bear has joined
05:06:41 bear has left
05:10:00 m&m has left
09:00:27 Tobias has joined
11:33:35 Tobias has left
11:33:42 Tobias has joined
11:48:21 Tobias has left
11:48:28 Tobias has joined
11:50:18 Tobias has left
11:50:26 Tobias has joined
12:04:32 Tobias has left
12:52:53 Zash has joined
13:19:10 Tobias has joined
13:50:12 Kev has left
13:57:37 Zash has left
14:07:49 Zash has joined
14:53:01 Zash has left
14:53:02 Zash has joined
14:57:36 m&m has joined
15:09:58 Zash has joined
15:24:50 ralphm has joined
15:47:00 Tobias when should one use a stream-feature and what are the alternatives?
15:49:14 Zash Features related to the stream itself?
15:51:00 Lance has joined
15:51:00 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
15:51:14 Tobias heh
15:52:01 Kev That doesn't happen until you send your initial presence.
15:52:10 Tobias right
15:52:15 Kev So it doesn't seem that it needs a stream feature to stop it.
15:52:28 Tobias so it could be in caps?
15:52:38 Tobias s/caps/disco?
15:52:47 bear has joined
15:53:05 Kev Could be in caps, even, yes.
15:53:23 Tobias hmm....
15:54:52 Kev Although you'd get the presence if they were online, so ... :)
15:55:35 Tobias hmm...
15:55:47 Tobias or could stanza filtering filter that out
15:55:56 Tobias didn't we have a XEP for that?
15:56:50 Zash SIFT
15:57:31 Tobias could it filter delayed delivery out of presence stanzas?
15:58:29 m&m SIFT didn't get that specific, but it is extensible
15:58:36 m&m meaning, you can add new conditions
15:59:44 Zash Tobias: Some servers already send unavailable presence
15:59:52 Zash So that traffic already exists.
15:59:57 Kev Right.
16:00:08 Tobias so nothing we can do about it?
16:00:28 ralphm Cry?
16:00:31 m&m from a server to the client, SIFT (possibly with a special extension) should be able to do what you want
16:00:39 ralphm but what m&m says
16:00:42 m&m the trick is to get servers to implement it (-:
16:00:59 Zash Someone argued that it made sense to drop such unavailable presence
16:01:04 m&m I bet MattJ will have it done in prosody by lunch tomorrow if you asked nicely
16:01:19 Zash m&m: Wait, for what?
16:01:29 m&m (-:
16:01:38 ralphm is MattJ up and running again?
16:01:41 m&m for the "SIFT-unavailable-with-delay"
16:01:46 Zash Ah
16:02:10 Zash I wrote a plugin yesterday to filter out unavailable in response to probes if it had no childs
16:02:51 Kev And ding ding ding.
16:02:57 ralphm Zash: what is the exact issue with the offline presences
16:03:03 Kev 1) Roll call
16:03:05 Kev I'm here!
16:03:07 ralphm Zash: after the meeting
16:03:07 m&m presente
16:03:09 ralphm I'm here
16:03:10 Tobias same here
16:03:26 Kev And I'm assuming we have continued apologies from MattJ until we hear otherwise.
16:03:36 Zash He said he was going to be here
16:03:42 ralphm anyone know how is these days?
16:03:44 Kev Zash: Ah, OK. Maybe he will.
16:03:50 Kev ralphm: I've not spoken to him at all.
16:04:16 Kev I'd worry, but he got word through to Peter that he'd be offline, so I just hope he gets fixed soon.
16:04:30 Kev Aaaaanyway.
16:04:42 MattJ has joined
16:04:44 m&m notes stpeter just walked into the office
16:04:44 Kev 2) Peter'd like to issue an LC on 152 (Reachability Addresses)
16:05:01 Kev MattJ: Welcome back.
16:05:02 m&m normally I'd be +1 on LC
16:05:10 MattJ Hey :)
16:05:24 Kev m&m: There's a "but"
16:05:30 MattJ Never gladder to attend a meeting before
16:05:32 m&m IETF is kicking my butt
16:05:33 ralphm MattJ: WB!
16:05:43 m&m and the meeting hasn't even happened yet!
16:05:57 m&m I and stpeter might be the only ones in this predicament
16:06:02 ralphm IETF doesn't want to be reachable/
16:06:03 ralphm ?
16:06:18 m&m ralphm: opposite problem, it's too reachable
16:06:28 Kev m&m:So you'd like to delay the LC on 152 until after the IETF meeting?
16:06:41 m&m anyway, I've no objections to LC, but I would like to extend the deadline by a couple of weeks
16:06:47 ralphm sure thing
16:06:48 m&m Kev: or that
16:06:52 Kev A one-month LC, then?
16:07:04 ralphm Long Call
16:07:10 ralphm I am up for that
16:07:13 Kev LCLC
16:07:19 Kev Or LC^2.
16:07:20 m&m either works for me, although delaying would probably work out better for my inbox (-:
16:07:27 Zash L²C
16:07:30 m&m heh
16:07:37 m&m Zash wins
16:07:48 Kev Congratulations.
16:07:59 Zash \o/
16:08:08 Kev MattJ: Opinion?
16:08:50 MattJ I have some catching up to do
16:09:05 waqas has joined
16:09:20 Tobias later or longer last call are either fine with me
16:09:44 MattJ Longer LCs are fine by me in general
16:09:58 stpeter has joined
16:09:59 m&m as long as we remember the deadline
16:10:04 stpeter oops :-)
16:10:06 MattJ We've had to extend LCs multiple times in the past
16:10:09 m&m which reminds me, I have some BOSH patches to submit
16:10:13 Kev I trust Peter to remember the deadline :D
16:10:23 stpeter MattJ!!!
16:10:25 ralphm ☎
16:10:28 Tobias that's what we have a calendar for, not?
16:10:28 MattJ stpeter!!
16:10:31 stpeter ralphm: :-)
16:10:42 m&m Tobias!!!
16:10:53 stpeter checks http://logs.xmpp.org/council/130220/
16:10:54 Kanchil stpeter: http://logs.xmpp.org/council/130220/: Chatroom logs for council@muc.xmpp.org (Wednesday, February 20, 2013)
16:10:54 Kev MattJ: Are you OK with an LC on this one?
16:11:10 MattJ +1
16:11:38 Kev Excellent.
16:11:44 Kev 3) Date of next meeting?
16:11:51 Kev SBTSBC?
16:11:59 Tobias wfm
16:12:08 m&m yes, as long as we keep extending the deadlines (-:
16:12:48 ralphm 👍
16:13:15 Kev ralphm: I'm going to assume that's the special unicode glyph pair for "works for me" :)
16:13:17 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
16:13:26 ralphm THUMBS UP SIGN (U+1F44D)
16:13:40 m&m oh, unicode
16:13:40 Kev Was it? o_O
16:13:52 Kev Oh, yes, that's very different.
16:14:03 Kev In the font Swift uses it looked like a left sleeve and a right sleeve.
16:14:14 Kev Anyway.
16:14:23 Kev 4) Any other business
16:14:30 Kev I think Peter'd like to ask us to go look at WG stuff.
16:14:36 Kev (Precis)
16:14:37 stpeter right :-)
16:14:39 m&m Yes. When can we advance −308 to draft?
16:15:08 Kev Yeah, Gunnar was chasing me about that the other day (in a mail that went straight to spam, bad dog Gmail).
16:15:24 m&m heh
16:15:24 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.
16:15:26 ralphm Kev: it is not a glyph pair?
16:15:36 m&m Tobias: tentatively
16:15:39 Kev I'll try desperately to address LC feedback as soon as I've got a spare cycle.
16:15:48 m&m /nod
16:15:51 m&m I
16:15:51 stpeter Tobias: yes, that seems fine, but I need to look at it in detail still (next week)
16:15:52 m&m gah
16:15:59 ralphm what stpeter says
16:16:04 m&m I've got internal teams asking about the status
16:16:07 m&m of 308
16:16:08 stpeter :-)
16:16:09 Kev Tobias: It needs something for uptime, too. That one's widely deployed, and is even used. Although I'd rather something better :)
16:16:39 Tobias Kev, yeah...directed presence probes to hosts with delayed delivery response :)
16:16:42 Zash available presence + delayed?
16:16:49 Tobias i'll mention it in the informational XEP
16:16:56 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.
16:17:08 m&m Kev: I feel your pain
16:17:32 Kev Any other any other business?
16:17:38 stpeter Kev: need co-authors?
16:17:47 Kev stpeter: I think I just need a few hours.
16:17:51 Kev stpeter: Or a time machine.
16:17:53 stpeter Kev: which you don't have!
16:18:25 Kev I'll get to it. Maybe I'll have some minutes watching films with Cath at the weekend or something.
16:18:31 stpeter :/
16:18:32 stpeter ok
16:18:37 stpeter for Kev's sake, I think we're done
16:18:42 m&m /nod
16:18:43 Tobias yup
16:18:56 Kev i have nothing else, at least.
16:18:58 Kev Right.
16:19:01 Kev Thanks all.
16:19:06 Kev bangs the gavel.
16:19:11 m&m goes to talk to stpeter about DNA
16:19:24 stpeter yay :-)
16:19:28 Zash so
16:19:46 Kev Deoxyribonucleic acid? :)
16:19:48 Zash ralphm: Offline presence in response to probes are redundant, unless they carry some kind of extended data, like delayed delivery.
16:20:07 m&m Kev: very close. Domain Name Associations (or Assertions)
16:20:10 stpeter draft-saintandre-xmpp-dna
16:20:12 Kev Yes, I knew.
16:20:14 Kev Really.
16:20:16 m&m (-:
16:20:46 ralphm Zash: arguably they also tell you that you still have a presence subscription and that the remote host is reachable.
16:22:07 Zash ralphm: Right. Otoh it's traffic you may or may not want. The person who wanted this filter works on a mobile client
16:22:27 ralphm so, for a mobile client, I can think of two considerations
16:22:32 bear has left
16:22:34 ralphm 1) battery, 2) bandwidth
16:23:13 ralphm For case 1) I'd argue that it is very likely that your antenna is in fully up mode when you receive it.
16:23:23 ralphm For case 2) I'm pretty sure it compresses quite well
16:23:39 Kev And for (1) you want something like google:queue.
16:23:40 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?
16:23:45 ralphm (playing devil's advocate)
16:24:02 ralphm Zash: *maybe*
16:24:03 Kev Zash: Yes.
16:24:12 Kev Well, you needn't get an error.
16:24:19 Kev You will get unsubscribed for no longer having a sub.
16:24:50 ralphm Not for 3921 implementations
16:25:30 Kev That's true.
16:25:46 Zash Oh
16:26:29 ralphm So, as I said, arguably they do carry information.
16:26:36 ralphm Which doesn't invalidate your case
16:26:53 ralphm but we should do google-queue/SIFT
16:28:09 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?
16:28:14 Lance ralphm a 3) issue is the effect on startup time for the app, which IIRC was the issue raised by the mobile developer
16:28:25 Kev Zash: Yes.
16:28:45 Kev Lance: It shouldn't affect startup time for the app. It's all async.
16:29:09 Kev Not other than is covered by (2) anyway.
16:29:53 Zash If s2s setup for sending probes takes a long time, it might even lower the radio state before it gets replies
16:30:07 ralphm Zash: hence google-queue
16:30:25 Zash Yes
16:30:32 ralphm you wouldn't get those until you'd send something or receive a normal message
16:30:45 ralphm I don't really believe in 3) for properly designed applications
16:30:53 Kev Saying that.
16:31:02 Kev This really does hurt clients.
16:31:16 Kev That's why the stpeter roster test is nasty.
16:31:41 ralphm Kev: so is that because of badly written clients or the shear amount of data that has to be sifted through?
16:31:54 ralphm (genuinly curious)
16:32:02 Kev ralphm: I spent a very long time profiling and tuning Swift for this - it's the roster updates.
16:32:15 Kev The roster's sorted and every time you get a new presence that may potentially update the roster order.
16:32:37 ralphm oh, hmm
16:33:04 ralphm how did you resolve that? delayed updating the roster order?
16:33:04 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.
16:33:21 Kev No, just fiddling with data structures.
16:33:51 Kev Maps instead of vectors for finding the JID in the roster makes a hell of a difference.
16:34:21 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.
16:34:36 Kev Modern hardware will obviously improve this dramatically.
16:34:45 ralphm so but in this case, we are talking about unavailable presence
16:34:53 ralphm that wouldn't affect anything in the roster
16:35:01 Kev It does, somewhat.
16:35:12 Kev It doesn't cause a redraw (unless you have a status as well).
16:35:31 Kev But it does need you to do all of the data structure walking to find that it doesn't cause an update.
16:35:43 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
16:36:07 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?
16:36:24 Kev I just update the model, and let Qt manage when the redraws happen.
16:36:52 ralphm Kev: sure, but I assume you can batch that, too
16:37:02 Kev It wasn't paint calls themselves that were appearing in the profiling, at the point that I stopped work on it.
16:37:22 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 :)
16:37:43 ralphm hah
16:38:31 Ge0rG has joined
16:39:01 Lance and here's the one behind the issue. hey Ge0rG
16:39:08 Ge0rG hi! I'm Georg from yaxim.org
16:39:14 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?
16:39:41 ralphm hah, that's funny. I was just thinking about how yaxim also doesn't seem to like large rosters :-)
16:39:55 Zash ralphm: This is the guy
16:39:57 Ge0rG there is roster versioning, which reduces the overhead; but it only eliminates half of the traffic when connecting
16:40:12 ralphm Zash: awesome. We are full circle.
16:40:50 Ge0rG delaying UI/storage updates on incoming presences is only a mitigation measure... the incoming traffic still remains
16:41:01 xnyhps has joined
16:41:09 bear has joined
16:42:25 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)
16:43:24 Kev ralphm: What's your largest roster group, and how many do you have?
16:44:30 Ge0rG ralphm: yaxim is storing roster+presences in sqlite, with ca. 100ms of writing time for every. single. item.
16:44:55 Kev That sounds like a good thing to not do, then :)
16:44:56 ralphm 27 roster groups totalling 343 contacts. The largest one is 45
16:45:12 Kev ralphm: That sounds sufficiently small that it shouldn't cause too many issues.
16:45:17 ralphm Kev: right
16:45:18 Ge0rG yes, I am currently preparing a huge rework of the backend; but it will take time
16:45:21 Kev Same order of magnitude as my roster (although larger).
16:45:39 ralphm Kev: so I assume Ge0rG has some work cut out for him
16:45:47 Ge0rG and I do not really see a reason in delivering bare-jid unavailable presences (as unavialable is probably the default state anyway)
16:46:00 ralphm nevertheless, something like XEP-0305 might also be useful for our TCP binding
16:46:27 ralphm Ge0rG: http://logs.xmpp.org/council/130220/
16:46:28 Kanchil ralphm: http://logs.xmpp.org/council/130220/: Chatroom logs for council@muc.xmpp.org (Wednesday, February 20, 2013)
16:46:46 ralphm Ge0rG: we did some talking about it before you joined
16:47:34 Kev ralphm: I think 305 doesn't help at all here, actually.
16:47:48 Ge0rG 198 would help...
16:47:55 Ge0rG provided you had a session before
16:47:58 Kev Right.
16:48:07 ralphm Kev: I'm sorry, I meant 198 of course
16:48:25 Kev Right, 198's fine as long as you have an existing session.
16:48:29 Kev But for initial login you don't.
16:48:34 Ge0rG but not for initial connection, or if you have been offline for a longer time (5 or 30mins in prosody?)
16:48:55 Zash Ge0rG: Configurable, defaults to something like 5min
16:49:00 ralphm but you can throw away the unavailables right after having parsed them
16:49:10 Zash It would be nice to have some way to suspend a session so it wouldn't timeout
16:49:12 Kev ralphm: No, you can't.
16:49:24 ralphm Kev: if he thinks they are useless you can
16:49:37 Kev ralphm: Right, but you can't know they're useless until after you've checked against the roster.
16:49:39 Ge0rG ralphm: for that you need to check the previous state of the JID
16:49:47 Kev Although if sqlite is the bottleneck here, you can certainly easily bin them before that.
16:50:11 ralphm Kev: that was my point
16:50:15 Ge0rG also, not everybody can use tls/stream compression, and data traffic is not free everywhere in the world
16:50:37 ralphm well, ehm
16:50:41 Kev Ah, that's interesting.
16:50:47 Kev Why would you not be able to use stream compression?
16:50:51 Ge0rG so what is the additional information carried by presence-unavailable from bare JIDs in 3921 implementations?
16:51:16 Kev Ge0rG: Nothing, but 3921's obsoleted now.
16:51:21 ralphm it is actually likely they wouldn't send them
16:51:28 Kev Or, well, sometimes nothing, depending whether there was a <status/> there
16:51:44 Ge0rG ralphm mentioned 3921 as part of the pro-transmitting argument
16:51:52 ralphm Ge0rG: I did
16:51:57 ralphm Ge0rG: the point is that you can't know
16:52:00 Ge0rG which I am trying to understand now
16:52:21 Ge0rG Kev: stream compression is buggy in certain client-server combinations (I blame openfire, but not enough datapoints yet)
16:52:27 Kev Ah.
16:52:30 ralphm Ge0rG: some implementations will not send them, some will send unsubscribe (and some not) and some will send an error (or not)
16:52:41 Ge0rG Kev: https://github.com/pfleidi/yaxim/issues/85
16:52:41 Kev Yes, indeed, I remember something about OpenFire's compression stuff being broken.
16:52:57 ralphm do blame openfire
16:53:00 ralphm :-)
16:53:09 Ge0rG but blaming openfire will not fix the real-world problem for my users
16:53:15 Kev Ge0rG: No, indeed.
16:53:19 Ge0rG and they will blame yaxim instead
16:53:32 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
16:53:50 Ge0rG ralphm: if old implementations are not guaranteed to send anything, why would we demand new implementations to send a presence-unavailable?
16:54:01 Zash There is no demand
16:54:02 Kev We don't, do we?
16:54:06 ralphm We don't
16:54:08 Zash It's a SHOULD
16:54:09 ralphm we allow it
16:54:13 Kev Zash: Ah, is it?
16:54:17 Kev That's domanding it, then.
16:54:26 Ge0rG thats why I am asking
16:54:26 ralphm Unfortunately I have to go for dinner
16:54:33 Zash Kev: It is?
16:54:40 Ge0rG so my suggestion would be to change it into a SHOULD NOT :P
16:55:11 ralphm this will not help your case
16:55:19 ralphm at least not very soon
16:55:22 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.
16:55:22 Ge0rG ok, actually it needs some more context explanation
16:55:43 Kev Until you receive your first presence from them you've no idea if they're online or offline.
16:55:53 Ge0rG Kev: but you should assume the remote user is unavailable by default...
16:56:17 Ge0rG or there should be yet another presence state "unknown"
16:56:28 Zash The behaviour where the server tries to keep a consistent view of the availability of contacts at all times would help this
16:56:41 Zash was it Dave who wrote about that?
16:58:34 Ge0rG [offtopic] is there an (http) API to look up the XEP name given the number?
16:58:48 Zash Ge0rG: Sorta
16:59:02 Zash There's an XML file
16:59:02 Kev !xep 198
16:59:03 Kanchil Kev: XEP-0198(sm): http://xmpp.org/extensions/xep-0198.html Stream Management - Standards Track/Draft - Updated: 2011-06-29
16:59:26 Zash Ge0rG: Or, if you know the number, just stick it into that url
16:59:52 Ge0rG Zash: I want name and number, for a jekyll plugin
17:00:15 Ge0rG you know, if you are doing something, do it right the first time :)
17:00:19 Zash Ge0rG: http://xmpp.org/extensions/xeps.xml
17:01:13 Ge0rG cool, thanks
17:01:25 Zash http://web.archive.org/web/20120208104426/http://blog.dave.cridland.net/?p=144
17:01:26 Kanchil Zash: http://web.archive.org/web/20120208104426/http://blog.dave.cridland.net/?p=144: Advice to Santa on fast presence delivery – text/plain
17:01:39 Kev FWIW, when talking about 'doing it right first time', having played with both jekyll and nanoc, I prefer nanoc.
17:01:59 Ge0rG I'm not going to jump trains again ;)
17:02:06 Kev Fair enough.
17:02:08 Kev I did, FWIW.
17:02:15 Kev (Wordpress->jekyll->nanoc)
17:02:22 Ge0rG I's been only two weeks since I set up http://yaxim.org/
17:02:22 Kanchil Ge0rG: http://yaxim.org/: yaxim - yaxim
17:02:28 Ge0rG and it is good enough
17:02:32 Kev OK.
17:03:05 Kev Ah, maybe octopress makes things less bad.
17:03:16 nulani has joined
17:09:44 Lance has left
17:10:32 Tobias has joined
17:17:54 Neustradamus has joined
17:42:38 nulani has left
17:47:28 xnyhps has left
17:47:32 xnyhps has joined
18:01:28 stpeter has left
18:22:03 ralphm has left
18:22:12 ralphm has joined
18:29:29 Neustradamus has joined
18:29:46 Neustradamus has joined
18:58:55 ralphm bye, again, jabber.org
18:59:01 ralphm :-/
19:02:41 xnyhps has left
19:06:57 stpeter has joined
19:09:48 xnyhps has joined
19:15:27 ralphm has left
19:15:34 ralphm has joined
20:35:33 Kev That one was my fault.
20:35:35 Kev I did a stupid.
20:38:14 ralphm Kev: don't do stupids
20:38:39 Kev Excellent advice.
20:38:46 Kev I cannot fault it.
20:38:52 ralphm I am also not sure it is all right now
20:39:03 ralphm I cannot join a MUC at conference.ik.nu from jabber.org
20:54:30 Tobias has joined
21:00:39 Tobias has joined
22:14:05 stpeter has left
22:35:16 Neustradamus has joined
22:49:15 ralphm has left
22:49:25 ralphm has joined
23:04:27 Tobias has left
23:05:20 m&m has left
23:07:23 Tobias has joined
23:08:57 waqas has left
23:19:53 Tobias has left
23:31:58 Tobias has joined