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