Tobiaswhen should one use a stream-feature and what are the alternatives?
ZashFeatures related to the stream itself?
Lancehas joined
Tobiasthe 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
Tobiasheh
KevThat doesn't happen until you send your initial presence.
Tobiasright
KevSo it doesn't seem that it needs a stream feature to stop it.
Tobiasso it could be in caps?
Tobiass/caps/disco?
bearhas joined
KevCould be in caps, even, yes.
Tobiashmm....
KevAlthough you'd get the presence if they were online, so ... :)
Tobiashmm...
Tobiasor could stanza filtering filter that out
Tobiasdidn't we have a XEP for that?
ZashSIFT
Tobiascould it filter delayed delivery out of presence stanzas?
m&mSIFT didn't get that specific, but it is extensible
m&mmeaning, you can add new conditions
ZashTobias: Some servers already send unavailable presence
ZashSo that traffic already exists.
KevRight.
Tobiasso nothing we can do about it?
ralphmCry?
m&mfrom a server to the client, SIFT (possibly with a special extension) should be able to do what you want
ralphmbut what m&m says
m&mthe trick is to get servers to implement it (-:
ZashSomeone argued that it made sense to drop such unavailable presence
m&mI bet MattJ will have it done in prosody by lunch tomorrow if you asked nicely
Zashm&m: Wait, for what?
m&m(-:
ralphmis MattJ up and running again?
m&mfor the "SIFT-unavailable-with-delay"
ZashAh
ZashI wrote a plugin yesterday to filter out unavailable in response to probes if it had no childs
KevAnd ding ding ding.
ralphmZash: what is the exact issue with the offline presences
Kev1) Roll call
KevI'm here!
ralphmZash: after the meeting
m&mpresente
ralphmI'm here
Tobiassame here
KevAnd I'm assuming we have continued apologies from MattJ until we hear otherwise.
ZashHe said he was going to be here
ralphmanyone know how is these days?
KevZash: Ah, OK. Maybe he will.
Kevralphm: I've not spoken to him at all.
KevI'd worry, but he got word through to Peter that he'd be offline, so I just hope he gets fixed soon.
KevAaaaanyway.
MattJhas joined
m&mnotes stpeter just walked into the office
Kev2) Peter'd like to issue an LC on 152 (Reachability Addresses)
KevMattJ: Welcome back.
m&mnormally I'd be +1 on LC
MattJHey :)
Kevm&m: There's a "but"
MattJNever gladder to attend a meeting before
m&mIETF is kicking my butt
ralphmMattJ: WB!
m&mand the meeting hasn't even happened yet!
m&mI and stpeter might be the only ones in this predicament
ralphmIETF doesn't want to be reachable/
ralphm?
m&mralphm: opposite problem, it's too reachable
Kevm&m:So you'd like to delay the LC on 152 until after the IETF meeting?
m&manyway, I've no objections to LC, but I would like to extend the deadline by a couple of weeks
ralphmsure thing
m&mKev: or that
KevA one-month LC, then?
ralphmLong Call
ralphmI am up for that
KevLCLC
KevOr LC^2.
m&meither works for me, although delaying would probably work out better for my inbox (-:
ZashL²C
m&mheh
m&mZash wins
KevCongratulations.
Zash\o/
KevMattJ: Opinion?
MattJI have some catching up to do
waqashas joined
Tobiaslater or longer last call are either fine with me
MattJLonger LCs are fine by me in general
stpeterhas joined
m&mas long as we remember the deadline
stpeteroops :-)
MattJWe've had to extend LCs multiple times in the past
m&mwhich reminds me, I have some BOSH patches to submit
Kanchilstpeter: http://logs.xmpp.org/council/130220/:
Chatroom logs for council@muc.xmpp.org (Wednesday, February 20, 2013)
KevMattJ: Are you OK with an LC on this one?
MattJ+1
KevExcellent.
Kev3) Date of next meeting?
KevSBTSBC?
Tobiaswfm
m&myes, as long as we keep extending the deadlines (-:
ralphm👍
Kevralphm: I'm going to assume that's the special unicode glyph pair for "works for me" :)
stpetery'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
ralphmTHUMBS UP SIGN (U+1F44D)
m&moh, unicode
KevWas it? o_O
KevOh, yes, that's very different.
KevIn the font Swift uses it looked like a left sleeve and a right sleeve.
KevAnyway.
Kev4) Any other business
KevI think Peter'd like to ask us to go look at WG stuff.
Kev(Precis)
stpeterright :-)
m&mYes. When can we advance −308 to draft?
KevYeah, Gunnar was chasing me about that the other day (in a mail that went straight to spam, bad dog Gmail).
m&mheh
Tobiashere....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.
ralphmKev: it is not a glyph pair?
m&mTobias: tentatively
KevI'll try desperately to address LC feedback as soon as I've got a spare cycle.
m&m/nod
m&mI
stpeterTobias: yes, that seems fine, but I need to look at it in detail still (next week)
m&mgah
ralphmwhat stpeter says
m&mI've got internal teams asking about the status
m&mof 308
stpeter:-)
KevTobias: It needs something for uptime, too. That one's widely deployed, and is even used. Although I'd rather something better :)
TobiasKev, yeah...directed presence probes to hosts with delayed delivery response :)
Zashavailable presence + delayed?
Tobiasi'll mention it in the informational XEP
Kevm&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.
m&mKev: I feel your pain
KevAny other any other business?
stpeterKev: need co-authors?
Kevstpeter: I think I just need a few hours.
Kevstpeter: Or a time machine.
stpeterKev: which you don't have!
KevI'll get to it. Maybe I'll have some minutes watching films with Cath at the weekend or something.
stpeter:/
stpeterok
stpeterfor Kev's sake, I think we're done
m&m/nod
Tobiasyup
Kevi have nothing else, at least.
KevRight.
KevThanks all.
Kevbangs the gavel.
m&mgoes to talk to stpeter about DNA
stpeteryay :-)
Zashso
KevDeoxyribonucleic acid? :)
Zashralphm: Offline presence in response to probes are redundant, unless they carry some kind of extended data, like delayed delivery.
m&mKev: very close. Domain Name Associations (or Assertions)
stpeterdraft-saintandre-xmpp-dna
KevYes, I knew.
KevReally.
m&m(-:
ralphmZash: arguably they also tell you that you still have a presence subscription and that the remote host is reachable.
Zashralphm: Right. Otoh it's traffic you may or may not want. The person who wanted this filter works on a mobile client
ralphmso, for a mobile client, I can think of two considerations
bearhas left
ralphm1) battery, 2) bandwidth
ralphmFor case 1) I'd argue that it is very likely that your antenna is in fully up mode when you receive it.
ralphmFor case 2) I'm pretty sure it compresses quite well
KevAnd for (1) you want something like google:queue.
ZashIf 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?
ralphm(playing devil's advocate)
ralphmZash: *maybe*
KevZash: Yes.
KevWell, you needn't get an error.
KevYou will get unsubscribed for no longer having a sub.
ralphmNot for 3921 implementations
KevThat's true.
ZashOh
ralphmSo, as I said, arguably they do carry information.
ralphmWhich doesn't invalidate your case
ralphmbut we should do google-queue/SIFT
Zashgoogle-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?
Lanceralphm a 3) issue is the effect on startup time for the app, which IIRC was the issue raised by the mobile developer
KevZash: Yes.
KevLance: It shouldn't affect startup time for the app. It's all async.
KevNot other than is covered by (2) anyway.
ZashIf s2s setup for sending probes takes a long time, it might even lower the radio state before it gets replies
ralphmZash: hence google-queue
ZashYes
ralphmyou wouldn't get those until you'd send something or receive a normal message
ralphmI don't really believe in 3) for properly designed applications
KevSaying that.
KevThis really does hurt clients.
KevThat's why the stpeter roster test is nasty.
ralphmKev: so is that because of badly written clients or the shear amount of data that has to be sifted through?
ralphm(genuinly curious)
Kevralphm: I spent a very long time profiling and tuning Swift for this - it's the roster updates.
KevThe roster's sorted and every time you get a new presence that may potentially update the roster order.
ralphmoh, hmm
ralphmhow did you resolve that? delayed updating the roster order?
KevSo 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.
KevNo, just fiddling with data structures.
KevMaps instead of vectors for finding the JID in the roster makes a hell of a difference.
KevI 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.
KevModern hardware will obviously improve this dramatically.
ralphmso but in this case, we are talking about unavailable presence
ralphmthat wouldn't affect anything in the roster
KevIt does, somewhat.
KevIt doesn't cause a redraw (unless you have a status as well).
KevBut it does need you to do all of the data structure walking to find that it doesn't cause an update.
Lancekind 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
ralphmBut did you really do a redraw for every presence? One of the first things I'd try is delaying it by, maybe, a second?
KevI just update the model, and let Qt manage when the redraws happen.
ralphmKev: sure, but I assume you can batch that, too
KevIt wasn't paint calls themselves that were appearing in the profiling, at the point that I stopped work on it.
KevI'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 :)
ralphmhah
Ge0rGhas joined
Lanceand here's the one behind the issue. hey Ge0rG
Ge0rGhi! I'm Georg from yaxim.org
ralphmbut, 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?
ralphmhah, that's funny. I was just thinking about how yaxim also doesn't seem to like large rosters :-)
Zashralphm: This is the guy
Ge0rGthere is roster versioning, which reduces the overhead; but it only eliminates half of the traffic when connecting
ralphmZash: awesome. We are full circle.
Ge0rGdelaying UI/storage updates on incoming presences is only a mitigation measure... the incoming traffic still remains
xnyhpshas joined
bearhas joined
ralphmGe0rG: 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)
Kevralphm: What's your largest roster group, and how many do you have?
Ge0rGralphm: yaxim is storing roster+presences in sqlite, with ca. 100ms of writing time for every. single. item.
KevThat sounds like a good thing to not do, then :)
ralphm27 roster groups totalling 343 contacts. The largest one is 45
Kevralphm: That sounds sufficiently small that it shouldn't cause too many issues.
ralphmKev: right
Ge0rGyes, I am currently preparing a huge rework of the backend; but it will take time
KevSame order of magnitude as my roster (although larger).
ralphmKev: so I assume Ge0rG has some work cut out for him
Ge0rGand I do not really see a reason in delivering bare-jid unavailable presences (as unavialable is probably the default state anyway)
ralphmnevertheless, something like XEP-0305 might also be useful for our TCP binding
ralphmGe0rG: http://logs.xmpp.org/council/130220/
Kanchilralphm: http://logs.xmpp.org/council/130220/:
Chatroom logs for council@muc.xmpp.org (Wednesday, February 20, 2013)
ralphmGe0rG: we did some talking about it before you joined
Kevralphm: I think 305 doesn't help at all here, actually.
Ge0rG198 would help...
Ge0rGprovided you had a session before
KevRight.
ralphmKev: I'm sorry, I meant 198 of course
KevRight, 198's fine as long as you have an existing session.
KevBut for initial login you don't.
Ge0rGbut not for initial connection, or if you have been offline for a longer time (5 or 30mins in prosody?)
ZashGe0rG: Configurable, defaults to something like 5min
ralphmbut you can throw away the unavailables right after having parsed them
ZashIt would be nice to have some way to suspend a session so it wouldn't timeout
Kevralphm: No, you can't.
ralphmKev: if he thinks they are useless you can
Kevralphm: Right, but you can't know they're useless until after you've checked against the roster.
Ge0rGralphm: for that you need to check the previous state of the JID
KevAlthough if sqlite is the bottleneck here, you can certainly easily bin them before that.
ralphmKev: that was my point
Ge0rGalso, not everybody can use tls/stream compression, and data traffic is not free everywhere in the world
ralphmwell, ehm
KevAh, that's interesting.
KevWhy would you not be able to use stream compression?
Ge0rGso what is the additional information carried by presence-unavailable from bare JIDs in 3921 implementations?
KevGe0rG: Nothing, but 3921's obsoleted now.
ralphmit is actually likely they wouldn't send them
KevOr, well, sometimes nothing, depending whether there was a <status/> there
Ge0rGralphm mentioned 3921 as part of the pro-transmitting argument
ralphmGe0rG: I did
ralphmGe0rG: the point is that you can't know
Ge0rGwhich I am trying to understand now
Ge0rGKev: stream compression is buggy in certain client-server combinations (I blame openfire, but not enough datapoints yet)
KevAh.
ralphmGe0rG: some implementations will not send them, some will send unsubscribe (and some not) and some will send an error (or not)
KanchilZash: http://web.archive.org/web/20120208104426/http://blog.dave.cridland.net/?p=144:
Advice to Santa on fast presence delivery – text/plain
KevFWIW, when talking about 'doing it right first time', having played with both jekyll and nanoc, I prefer nanoc.
Ge0rGI'm not going to jump trains again ;)
KevFair enough.
KevI did, FWIW.
Kev(Wordpress->jekyll->nanoc)
Ge0rGI's been only two weeks since I set up http://yaxim.org/
KanchilGe0rG: http://yaxim.org/:
yaxim - yaxim
Ge0rGand it is good enough
KevOK.
KevAh, maybe octopress makes things less bad.
nulanihas joined
Lancehas left
Tobiashas joined
Neustradamushas joined
nulanihas left
xnyhpshas left
xnyhpshas joined
stpeterhas left
ralphmhas left
ralphmhas joined
Neustradamushas joined
Neustradamushas joined
ralphmbye, again, jabber.org
ralphm:-/
xnyhpshas left
stpeterhas joined
xnyhpshas joined
ralphmhas left
ralphmhas joined
KevThat one was my fault.
KevI did a stupid.
ralphmKev: don't do stupids
KevExcellent advice.
KevI cannot fault it.
ralphmI am also not sure it is all right now
ralphmI cannot join a MUC at conference.ik.nu from jabber.org