jdev - 2020-04-11

lovetox would you please add the request that you used to trigger the MAM bug you just reported in the ticket?

yes np

tx! Looking at it right now

Guus maybe you cant reproduce because you didnt include a rsm element

that might be it. I did get one in the resulting 'fin'

I'll have a look. Thanks for the report.

hm i see at least one thing that can be improved on Gajim side, i only include the date filter on the first query

lovetox this might be caused by the query returning data that was stored prior to Openfire supporting MAM:2

Guus i adjusted Gajim so it always includes the date filter in every page request

the problem is still there

so the server definitly does not look in the database for messages older than a day

or he wouldnt need to from my query

not sure what it really does

I'm thinking it doesn't include a first or last element if the corresponding message does not have a stable id

lovetox would you mind retrying on ignite?

I've rolled out a build that contains a fix

A snapshot release for the plugin will appear momentarily on https://www.igniterealtime.org/projects/openfire/plugin-archive.jsp?plugin=monitoring

this includes the fix, which you can use to test on other domains.

Guus, looks good now

lovetox: cool, tx

This might fix quite a bit of oddities around archive interaction in older MUCs.

Does anyone happen to feel like writing a kind of echo bot that tries to answer in the users language? Ie, reply "Hello" translated based on stanza @xml:lang

and make it finish with "Das war: $Language"

Sendung mit der Maus?

Or "Hello in English!" "Bonjour en français !"

Something to test how well xml:lang gets across the network.

Martin, YES!

As I see different clients using different styles of IDs for messages I assume there is no definition how they should look like. Is this right?

Martin, correct

Thanks.

hm anybody an idea why ejabberd would remove my delay element which i added to a stanza

<delay xmlns="urn:xmpp:delay" stamp="2020-04-11T16:03:18Z" from="lovetox@temptatio.dev/gajim.09IQM0NS" />

Holger ^

lovetox: No, and I can't reproduce it.

lovetox: If you can maybe we should continue in the ejabberd room?

(Protocol-wise, the only reason to strip a delay tag I see would be you setting an incorrect `from` address.)

Or a `from` of the server itself.

Or basically anything that's not your own full JID

yeah, but we know no server validates delay tags

so even then ..

i think i have an idea

hm i think thats a bug on my side

:/

I hear such things happen :)

i wonder how do people implement the resend of stanzas after resumption

currently i pass the stanza to the socket to send, but keep it around, add the delay element, and put it into a queue

but this poses the danger that i accidently for some reason have a reference somewhere else to that stanza and modify it after sending

and on resend i send something different then

now i could create a copy of the stanza before i queue it, but i wonder if its worth the overhead

I think the 198 implementation for Prosody also copies. Or it should. But that costs memory allocations.

the problem is i dont think my node structs are easily copyable

if i do it now, i would convert it to a string, and reparse it into a new node

true immutable data structures would have been nice

which is damn awful

costs memory tho