-
Sam
Is there anyone who has done an implementation of Message Styling that would be interested in using a shared set of unit tests to ensure compatibility?
-
nephele
Sam: What do the unit tests do, check the rendering of items or so?
-
Sam
nephele: yah, they take in a message and spit out what parts of the message should have what styles
-
nephele
Ah, so it's unit tests for the parser part
-
nephele
Are these for https://xmpp.org/extensions/xep-0393.html ?
-
Sam
yes
-
nephele
I am reading it, I'm quite lost on what a child block is, is this only in reference to nested quotes?
-
nephele
Anyway, I want to implement message formatting for Renga at some point or another, If i can figure out how to include unit tests that could be quite neat to have the same ones
-
pulkomandy
you can have unit tests in Renga by comparing the text_run_array in a BView with the expected output from the test, I guess? Sounds possible to do at least
-
nephele
I'm not sure if something like quotes could be represented with a text_run_array
-
lovetox
the more i look into python xml libs the more i believe xmpps decision to not use prefixes is actually the weird thing that nobody does
-
lovetox
i think one can say there i almost no support in libs for so called "default" namespaces
-
lovetox
pythons etree.Element, has no way of setting a default namespace, nor parsing it
-
lovetox
lxml supports them better, but it still fills like something which is a second class citizen
-
MattJ
lovetox, I've no idea what you mean... an XML library either supports namespaces or it doesn't. XMPP doesn't do anything weird, and there's not really any such thing as a "default namespace" in XML (actually there is, but let's not go there)
-
lovetox
i also thought that, but its not the case, or it depends what you mean by supports
-
lovetox
if you parse that with pythons included xml lib
-
lovetox
'<a xmlns="test" />'
-
lovetox
you get an object and if you serialise it back its
-
lovetox
'<ns0:a xmlns:ns0="test" />'
-
Zash
why the
-
Trbl
fk would you implement xmpp in python
-
flow
looks like a valid transformation?
-
Zash
looks like an excellent way to convince people that xml is scary and to use json instead
-
flow
even though not an optimal one
-
lovetox
flow how does that help me if xmpp says i should use no prefixes :D
-
Trbl
should or must
-
Trbl
i'd just say fuck it if its the first case
-
flow
probably not much, but then again, I think, at least those kind of prefixes are fine
-
flow
a different (and desirable) kind of prefixes are the ones that a declare in <stream/>✎ -
flow
a different (and desirable) kind of prefixes are the ones that a declared in <stream/> ✏
-
flow
those are probably likely to cause issues with certain impelementations
-
flow
but not the prefixes that are introduced by the transformation you showed
-
flow
assuming they are only done on a sub <stream/> level
-
lovetox
so every server will be ok if i send
-
lovetox
<ns0:message xmlns:ns0="jabber:client" />
-
lovetox
because that would be great :D
-
Zash
Prosody will be fine. ``` > util.xml.parse[[<ns0:message xmlns:ns0="jabber:client" />]] <message xmlns='jabber:client'/> ```
-
flow
lovetox, maybe not every server, but chances are high that the XML parser on the receiving end will handle it just fine
-
flow
but still, the transformation is not space-efficient, so you may want to avoid it
-
flow
maybe there is simple switch to change the behavior of serialiser?
-
Zash
space-efficiency would be to stuff a ton of namespace prefixes on the stream header
-
Zash
`<sm:r/>` etc
-
flow
sure, but let's do baby step and get this fixed first✎ -
flow
sure, but let's do baby steps and get this fixed first ✏
-
flow
Zash, would prosody support namespace declartions in <stream/>? if so, announce it as stream feature and I'll implement an optimization in Smack for it
-
Zash
All that's handled transparently by libexpat, so should work fine
-
Zash
The receiving/parsing side at least.
-
flow
Zash, then we should consider specifying a stream feature for this. so that clients can safely perform this optimization
-
flow
as I have heard that other servers bail on it
-
Zash
Sure
-
MattJ
But the stream feature comes after the client already sent the opening stream header...
-
Zash
Save it for the post-sasl stream restart
-
Zash
assuming we still have a stream restart in the future
-
MattJ
Carry state between the unauthed and authed streams?!
-
Zash
😱️
-
Zash
Maybe, one day, we should redesign the whole stream startup thing.
-
flow
if it's an non-TLS connection that its fine
-
flow
otherwise you have to announce the feature after TLS
-
flow
but before auth
-
flow
I think this should be safe?
-
Zash
Make it client-first, where it sends all the extensions it wants, and the server picks the parts it likes
-
MattJ
version='2.0'
-
Zash
Since this is the server telling the client things _after_ it has been authenticated with TLS & certs
-
Zash
no wait
-
Zash
aaaaargh, everything is backwards
-
Zash
or
-
Zash
so confused
-
Zash
Server does advertise things after it has been authenticated. Then the client authenticates. And then it does the thing.
-
Zash
So, should be fine?
-
flow
simply in the stream features of step 8 in RFC 6120 § 9.1.1
-
flow
then the client can declare the namespaces in step 13
-
flow
so besides the <mechanisms/> in <stream:features/> you have a <namespace-prefixes-in-stream/> flag
-
Zash
as a bonus, after the restart, throw in a namespaced attribute on the opening stream header to tell the server it's okay to do the same thing
-
Zash
`<stream:stream to="example.com" ns:prefixes="ok" xmlns:ns="urn:xmpp:tbd:namespaces-prefixes">` something something