jdev - 2021-11-05

c14n do i need that in xmpp? do i need to read up on that? ✏

I don't think so, although discussions around canonicalization come up once in a while

but with stanza routing hops may injecting new elements, modifying or deleted existing ones, it's probably unrealistic that c14n is in any sensible in xmpp

thanks

hm

how does xml:lang inheritence work with websocket?

as every websocket frame is its own document i guess not at all

so am i supposed to add xml:lang to every message

oh wow yes indeed thats how it works

that breaks everything, now i dont even have a document, just lose elementes ...

Dould have been nice do define a websocket variant without that framing hack

Yet people rejoiced at finally having framing, at the time

and consider streaming the hack :)

its just makes it really hard to abstract over these two different streaming methods

..

Hrrrrrrrr

flow: That's more or less what we do in M-Link, turn the document stream into a stream of top level elements. I imagine most things do the same.

Yes

maybe that's just another argument to not view the XMPP connection as an endless stream of an XML document, but instead a stream of individual XML elements: the XMPP top level stream elements ✏

em ... im not even sure how to do this

hm

but then i lose all the nice things the parser does for me

for example i need then to add jabber:client to all incoming stanzas

i need to do the same with xml:lang

if i treat it as a document, the xml parser does this all for me

Maybe you can do like what Prosody does, rewrite the websocket stream into an xmpp stream and parse that as usual

yes, i plan to add a dummy <root> element

i can even do <root xml:lang='en'>

hm no i cant

every stanza needs to be its own document ..

ok lets leave websolcket broken for now :D

That does not sound like what prosody does.

lovetox, Smack wraps every top-level stream element in a synthesized <stream/> with the relevant attributes set. Since it's only a handful of attributes, it's pretty easy

of course, things get a little bit more complicated if you consider e.g. namespace declarations in <stream/>, but that should also be no show stopper

Unless you rewrite `<open/>` into `<stream:stream>` and then feed everything into a normal stream parser

Zash, what happens then?

You can pretend it's a normal XMPP stream and parse it as such