jonaswis a stream closed wtih a stream error by the client SM-resumable?
marmistrzhas left
rtq3has joined
Valerianhas joined
Valerianhas left
Valerianhas joined
pep.has left
rishiraj22has left
rainslidehas joined
rishiraj22has left
rishiraj22has left
Kevhas left
rishiraj22has left
rishiraj22has left
Link MauveI’d say no.
jonaswthat’d mean that sending <connection-timeout/> on streams which one believes to be dead is a bad idea.
jonasweven though that might help with debugging
HolgerI'd say 'no' as well. Stream errors are unrecoverable. But formally speaking you could probably go into the definition of 'stream' vs. 'session' or how XEPs may override RFCs, while then again 0198 doesn't go into this.
Holgerjonasw: Yes I think that's a bad idea. Just close the TCP session.
jonaswgood
Holger... and log things locally for debugging.
jonaswmmm, I might even be sending </stream:stream> on timeouts in some cases, I need to look into that
j.rhas joined
jonasw(or have been sending, anyways, I reworked the whole timeout business and I think it’s much better now in any respect)
Holgerjonasw: Or if you think it would be good/important to support this, it should explicitly go into 0198, IMO.
jonaswwhich would namespace-bump '198. thanks, but no thanks.
jonasw(or maybe stream-feature it, but eh, I don’t want to handle that with a conditional thing)
jonaswbreaking layers too much
lnjhas left
rishiraj22has left
rishiraj22has left
rishiraj22has left
rishiraj22has left
rishiraj22has left
rainslidehas left
Kevhas left
rishiraj22has left
rishiraj22has left
doshas joined
ThibGhas joined
ThibGhas joined
rishiraj22has left
rishiraj22has left
rishiraj22has joined
rishiraj22has left
rishiraj22has joined
winfriedhas left
ralphmhas joined
efrithas left
rishiraj22has left
rishiraj22has joined
rishiraj22has left
rishiraj22has joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
jerehas joined
Neustradamushas left
Neustradamushas joined
Kevhas joined
Guushas left
Guushas left
j.rhas joined
j.rhas joined
Guushas left
Guushas left
Guushas joined
mrdoctorwhohas joined
Alexhas joined
vanitasvitaehas left
rainslidehas joined
alexishas joined
lumihas joined
rishiraj22has left
rishiraj22has joined
rainslidehas left
j.rhas joined
mimi89999has left
j.rhas joined
rishiraj22has left
rishiraj22has joined
mrdoctorwhohas joined
mrdoctorwhohas joined
nycohas left
nycohas joined
rishiraj22has left
nycohas left
danielhas left
nycohas joined
rishiraj22has joined
rishiraj22has left
jerehas joined
lorddavidiiihas left
rishiraj22has left
rishiraj22has left
rishiraj22has left
jerehas joined
rishiraj22has left
Ge0rGjonasw [13:49]:
> that’d mean that sending <connection-timeout/> on streams which one believes to be dead is a bad idea.
Bad idea indeed
danielGuus: maybe the Readme in github.com/inputmice/p2 can help?
Guustx
vanitasvitaehas left
Valerianhas left
Valerianhas joined
Neustradamushas joined
Valerianhas left
Valerianhas joined
Valerianhas left
karphas left
danielLet me know if that was in fact helpful. Maybe there is something left that I can clarify
j.rhas joined
Guusdaniel, I'm half way through it, and had two ah-hah! moment already.
Guus(not to be confused with a-ha moments: https://www.youtube.com/watch?v=djV11Xbc914 )
Guusgotta put my kids in bed now though, afk.
alexishas joined
j.rhas left
j.rhas joined
rainslidehas joined
j.rhas joined
alacerhas left
alacerhas joined
rishiraj22has left
lskdjfhas joined
rishiraj22has left
labdsfhas left
rainslidehas left
rishiraj22has left
Dave Cridlandhas left
rishiraj22has left
rtq3has left
rtq3has joined
jubalhhas joined
rtq3has left
rtq3has joined
alexishas left
Valerianhas joined
alexishas joined
lskdjfhas joined
j.rhas joined
j.rhas joined
lskdjfhas left
lskdjfhas joined
lskdjfhas left
Guusdaniel, so if I understand things correctly, then somewhere there's at least one of your P2 instances running that services the standard Conversations clients that are out there? (I can run my own, but that's only of interest if I build my own Conversations client?). Regular Conversations clients will perform "Account Owner Service Discovery" on the local XMPP domain, and, if available, this will eventually cause Conversations to ask the local XMPP domain to enable notifications (in that request a reference to the JID of your P2 instance is included)?
lskdjfhas joined
lskdjfhas joined
marmistrzhas left
lskdjfhas left
danielYes
danielAnd the jid of the P2 is hard-coded into Conversations. And if you compile that yourself you'd have to change that
GuusYeah, I'm not interested in doing that - I'm just checking if I understood the concept better now.
lumihas joined
GuusThanks, that helped a lot
lskdjfhas left
alexishas joined
SamWhitedhas left
labdsfhas left
Ge0rGhas left
Dave Cridlandhas left
lskdjfhas left
karphas left
karphas joined
muppethhas joined
jubalhhas joined
lskdjfhas left
lskdjfhas left
lskdjfhas left
jubalhhas left
lskdjfhas left
danielhas left
GuusIn a follow-up question to Push notifications: is there a list somewhere of good event candidates that warrant a push notification?
danielIf there is a hibernating or unresponsive session push on every stanza that is being send down stream (not held back by csi)
danielOtherwise push on everything that would land in the archive / offline message
danielThe thing you need to that is not described in the P2 Readme is that you should create a mapping between your push targets (app server jid - node ID tuple) and the current session
lskdjfhas left
danielSo you'll know whether a specific push target is currently connected or not
danielClients will send the enable in every session you know which session belongs to which push target
Dave Cridlandhas left
rishiraj22has left
Guusdid you just tell me to not send push notifications to an inactive (CSI) client?
Guusdoesn't that defeat the purpose?
HolgerGuus: Just not for those stanzas held back by CSI.
Guusah, right.
HolgerGuus: The idea is that you'd usually want the same filtering rules for disconnected push clients as for inactive TCP-connected clients.
labdsfhas left
Guusgot itj
Guusgot it*
tahas left
Andrew Nenakhovhas joined
labdsfhas left
Andrew Nenakhovhas joined
j.rhas joined
Marandahas joined
j.rhas joined
alexishas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Alexhas left
Alexhas joined
Valerianhas left
labdsfhas left
lskdjfhas left
danielhas left
la|r|mahas joined
lskdjfhas joined
rishiraj22has left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
muppethhas joined
rishiraj22has left
marmistrzhas left
Andrew Nenakhovhas left
muppethhas joined
Andrew Nenakhovhas joined
rishiraj22has left
rishiraj22has joined
MattJWhat if push was just the client registering a JID with it's server?
MattJAnd the server sent a simple <message> to that JID when it wanted to push something
danielHow is that different from how it works now
danielBesides IQ vs messages
alexishas joined
jubalhhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
karphas left
karphas joined
jubalhhas left
jubalhhas joined
jubalhhas left
labdsfhas left
jubalhhas joined
tahas left
jubalhhas joined
jubalhhas joined
jubalhhas joined
kasper.dementhas joined
tahas left
jubalhhas joined
jubalhhas left
MattJI guess it isn't, it's just a lot simpler
MattJThan pretending the app server is a pubsub service
MattJBut now I'm sounding like Ge0rG
labdsfhas left
jubalhhas joined
danielNot worth changing at this point IMHO. One could consider rewriting the entire xep to make it easier to understand while keeping the Syntax
anjanhas left
MattJI would probably drop all the stuff about the communication between the app server and the client
MattJI think people can figure that part out for themselves, and in reality it will be different in every case
HolgerMattJ: I think there's value in using an IQ to get an ACK or error back. Yes the PubSub syntax is useless and confusing, and even more so all that nonsense-talk around PubSub in the XEP. But now that we have it I'd go for just simplifying the language as daniel said.
MattJFair enough :/
zakhas joined
Zashhas left
SaltyBoneshas left
tahas left
HolgerYou want the IQ errors to let the app server notify you of dead push devices. The XEP also specifies an affiliation change <message/> in section #8 but that seems meh to me. I'd ditch that.
Ge0rGHolger: you wanted to write a PR against push to remove the nonsense.
Ge0rGReally, that xep is actively harmful. I don't know if just removing the misdirections while keeping the wire format will save it, but it's worth a try
HolgerGe0rG: I wanted to do that or you wanted me to want to do it? :-)
Holger> I would probably drop all the stuff about the communication between the app server and the client
+1
Kevhas left
lorddavidiiihas left
Ge0rGHolger: you said you'd take over authorship to fix it, but then Kev was first.
lskdjfhas left
HolgerWell those plans for 'fixing' the XEP were unrelated to the PubSub langauge. But whatever yes I'll try to find some time.
rionhas left
MattJHolger, messages can have error responses too...
ZashReceipts!
MattJI see the attraction of iq, but I don't think it's a given requirement
MattJOtherwise we should just do all messaging over iq
ZashMattJ: Hush, don't give them ideas
HolgerMattJ: In practice the ACK seems quite useful to me as well.
lskdjfhas left
Yagizahas left
lskdjfhas joined
foxtunehas joined
Zashhas left
Zashhas left
Wiktorhas left
HolgerMattJ: There's many hops in getting a push notification to the client, and when that fails you can be sure the problem is with one of the hops beyond the XMPP server.
lskdjfhas left
HolgerBut yes I could live with both.
Zashhas left
Holgers/both/either/
muppethhas joined
lskdjfhas left
lskdjfhas left
Zashhas left
lskdjfhas left
remkohas left
doshas joined
labdsfhas left
la|r|mahas left
marmistrzhas left
Marandahas joined
lskdjfhas joined
Wiktorhas left
Wiktorhas joined
alexishas left
muppethhas left
muppethhas joined
alexishas joined
Ge0rGhas joined
Ge0rGWith messages you could just send back error responses. Should be enough to find out which client is broken, right?
HolgerWe could replace all IQs with messages :-)
ZashNACK or ACK by default?
andyhas joined
marmistrzhas left
Zashhas left
HolgerYes, and follow-up with a ping IQ to make sure didn't just loose the connection to the app server!
rishiraj22has left
rishiraj22has joined
Holger*you didn't
j.rhas joined
nycohas left
lskdjfhas joined
lskdjfhas joined
la|r|mahas joined
Neustradamushas left
labdsfhas left
tuxhas left
Ge0rGGreat. Then next step will be to replace presence with messages as well.
MattJHolger, and what are you saying? The iq result should reflect successful delivery to the client or to the app server?
nycohas joined
HolgerMattJ: Just the app server, there's usually no (easy) way for the app server to acknowledge delivery to the client of course.
MattJRight
MattJSo to the app server, that can be solved with 198 already, though I don't think message loss on s2s is a common problem
alexishas joined
doshas joined
MattJUsing message /would/ allow an app server to generate errors from other layers
MattJif those other layers support it
ZashDoes it make sense to return >1 error responses?
ZashOr what would the difference be?
MattJYour message doubly failed to send
Guushas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
lskdjfhas left
rishiraj22has left
rishiraj22has joined
Andrew Nenakhovhas joined
Guushas left
ZashAs in, difference wrt iq
lskdjfhas left
jjrhhas left
HolgerThere's other error cases than s2s connection loss, and debugging them can be a PITA as multiple parties are involved with the delivery. Therefore I prefer an explicit ACK in the logs over an implicit success assumption based on missing error messages while debugging issues in practice.
lskdjfhas joined
HolgerBut yes, in a hypothetical world with ubiquitous s2s-0198 and robust app servers the implicit success assumption would work just as well.
XSF Discussion - 2018-06-13