SamDo any current pubsub implementations support result set management? The spec makes it sound like you can't use RSM from the get-go (it has its own separate way to set max-items and the only example just shows the server returning RSM information and no query using it), but I assume if you can use it on subsequent calls you could use it on the first call and I'm not sure what to do about the conflicting max items (that exist in pubsub and in RSM)?
machas left
Holgerejabberd's PubSub supports RSM.
SamThanks; I'll dig in and see what it does
Link Mauvesat_pubsub as well.
SamThis probably means I should actually get my ejabberd integration tests running again and figure out why it refuses to shut down cleanly
goffihas joined
kikuchiyohas joined
huhnhas left
defanorhas left
defanorhas joined
sonnyhas left
sonnyhas joined
emushas joined
marmistrzhas left
sonnyhas left
sonnyhas joined
Kevhas left
Kevhas joined
malthehas joined
malthehas left
marmistrzhas joined
dezanthas joined
dezanthas left
dezanthas joined
me9has joined
malthehas joined
dezanthas left
bunghas joined
antranigvhas left
sonnyhas left
sonnyhas joined
malthehas left
kikuchiyohas left
Yagizаhas joined
Kevhas left
Kevhas joined
kikuchiyohas joined
Kevhas left
Kevhas joined
spectrumhas left
goffihas left
goffihas joined
machas joined
goffihas left
goffihas joined
pulkomandyhas left
pulkomandyhas joined
machas left
Kevhas left
Kevhas joined
atomicwatchhas left
bunghas left
atomicwatchhas joined
goffihas left
bunghas joined
jgarthas joined
Alacer_dsrthas joined
sonnyhas left
sonnyhas joined
Kevhas left
Kevhas joined
selurveduhas left
sonnyhas left
spectrumhas joined
kikuchiyohas left
sonnyhas joined
Alacer_dsrthas left
alacerhas left
bunghas left
Kevhas left
Kevhas joined
marc0shas left
marc0shas joined
PapaTutuWawahas joined
flowthe question is, do ejabberd and sat_pubsub behave identical in all pubsub+rsm cases?
Ge0rGflow: will current versions of smack still fall-back to A/AAAA on the xmpp domain if SRV lookup times out / returns an unreachable host?
flowGe0rG, I think they should, yes
Ge0rGZash has set up client support on https://badxmpp.eu/ and when I try to connect to drop.badxmpp.eu it will end up on the A record and not on the SRV record.
machas joined
Ge0rGroughly 20% of yaxim connections are through yax.im:5222 despite the domain having valid SRV. I'm wondering how much of that is due to smack's incorrect fallback, and how much due to actually broken resolvers
flow> when I try to connect to drop.badxmpp.eu it will end up on the A record and not on the SRV record.
Isn't that the desired outcome? Or are you saying the information from the SRV record isn't used at all?
ZashIt seems to me you can't rely on SRV records. This makes me sad.
Ge0rGWell, if there is a timeout at resolving SRV, it should re-try resolving. If there is an SRV record, it should be used exclusively
Kevhas left
Link MauveA better fallback than 5222 might be WebSocket or BOSH as discovered by XEP-0156?
Kevhas joined
Zash> If the initiating entity receives a response to its SRV query but it is not able to establish an XMPP connection using the data received in the response, it SHOULD NOT attempt the fallback process described in the next section (this helps to prevent a state mismatch between inbound and outbound connections).
ZashNote: ≠ MUST NOT
flowGe0rG, "If there is an SRV record, it should be used exclusively " why?
ZashDino for example does the fallback anyways.
flowor, what's the harm in the fallback to A/AAAA?
Zashflow, SHOULD per https://xmpp.org/rfcs/rfc6120.html#tcp-resolution
flowin an ideal world, clients would discover all connection transports in parallel, following by trying to connect to all remote endpoints in parallel, and finally using only one
Kevhas left
Kevhas joined
ZashGe0rG, 20%? I believe you said 10% at some point in the past, is it getting worse?
flowfun, I actually misread the SHOULD NOT in the RFC as SHOULD (probably because that's what I expected here)
Kevhas left
Kevhas joined
flowalso not sure what "this helps to prevent a state mismatch between inbound and outbound connections" is about
Zashs2s? dunno
flowGe0rG, I should be possible to make the A/AAAA fallback configurable, if that's your desired behavior for yaxim
flowahh the state mismatch thingy probably makes sense in s2s only
ZashDoesn't make sense to me, but those words might fit in a s2s context.
flowbut for c2s I don't see any reason not to try the fallback to A/AAAA, besides the additional time until "could not connect" is returned
Kevhas left
Kevhas joined
Ge0rGflow: well, I'm not 100% sure what the "right" behaviour would be, but given what it is now, I can't just turn off the haproxy on yax.im:5222 forwarding to the real xmppd machine
Ge0rGZash: sorry, it's closer to 10% indeed. 273 out of 2561 c2s connections
ZashGoing for the fallback when you do have SRV records pointing elsewhere, in order to make it work, hides broken resolvers and whatnot, just like happy eyeballs hides broken IPv6. Then it never gets fixed and we can't ever have nice things.
flowGe0rG, irregardless of the right or wrong behavior, it would be interesting to see the exact trace of events that lead to the yax.im:5222 connections
Ge0rGflow: yes, but I'm not going to implement analytics in yaxim just out of that curiosity
flownot suggesting you should, just suggesting that there is some missing information
flowof all things, but I'd hoped that openwrt did the right thing™
flowI tend to believe that client devs need some in-the-field tracing of their clients to understand they various behavior in the wild
Ge0rGmaybe it's a ten-years old openwrt?
flowof course opt-in
Ge0rGlovetox: how old is your openwrt?
Ge0rGflow: how would it work? submit stack traces of failed connections?
flowGe0rG, stack traces are probably not enough, as certain prior events are also of interest. In general, you want the android log of the app and have the app (and smack) log the right events