jdev - 2020-02-23

  1. Neustradamus has left

  2. Neustradamus has joined

  3. gav has left

  4. Жокир has joined

  5. Жокир

    Is there a single client or server that is known to include cdata sections in its xml streams?

  6. timeline.menu has joined

  7. Жокир has left

  8. Жокир has joined

  9. timeline.menu has left

  10. Жокир has left

  11. Жокир has joined

  12. Жокир has left

  13. Sam Whited

    Not that I've ever seen. That would likely make it incompatible with most everything else

  14. Жокир has joined

  15. sonny has left

  16. Жокир has left

  17. Marc has left

  18. asterix has joined

  19. Жокир has joined

  20. lovetox has joined

  21. asterix has left

  22. asterix has joined

  23. sonny has joined

  24. Жокир has left

  25. pulkomandy has left

  26. pulkomandy has joined

  27. moparisthebest has left

  28. moparisthebest has joined

  29. lovetox has left

  30. asterix has left

  31. asterix has joined

  32. asterix has left

  33. asterix has joined

  34. asterix has left

  35. asterix has joined

  36. Martin has left

  37. Martin has joined

  38. tsk has left

  39. tsk has joined

  40. asterix has left

  41. asterix has joined

  42. asterix has left

  43. asterix has joined

  44. asterix has left

  45. asterix has joined

  46. marc0s has left

  47. marc0s has joined

  48. lovetox has joined

  49. asterix has left

  50. asterix has joined

  51. pulkomandy has left

  52. pulkomandy has joined

  53. asterix has left

  54. asterix has joined

  55. asterix has left

  56. asterix has joined

  57. goffi has joined

  58. Жокир has joined

  59. pulkomandy has left

  60. pulkomandy has joined

  61. Жокир

    Do clients and servers generally support namespace prefixes other than the usual "stream" referring to "http://etherx.jabber.org/streams"? I mean, sending the whole namespace url every time seems kind of silly and also wastes traffic. One good example would be "<r xmlns='urn:xmpp:sm:3'/>". The namespace url is longer than the actual message. With prefixes it could be shortened to e.g. "<s:r/>"

  62. asterix has left

  63. asterix has joined

  64. pulkomandy has left

  65. pulkomandy has joined

  66. Martin has left

  67. Martin has joined

  68. jonas’

    Жокир, no.

  69. jonas’

    last I tried that, things broke terribly

  70. jonas’

    it’s also a SHOULD NOT in RFC 6120, if I recall correctly

  71. Жокир has left

  72. jonas’

    ah, slightly different

  73. jonas’

    from 4.8.5, RFC 6120 <https://tools.ietf.org/html/rfc6120#section-4.8.5>: > Interoperability Note: For historical reasons, an implementation MAY accept only the prefix 'stream' for the stream namespace (resulting in prefixed names such as <stream:stream> and <stream: features>); this specification retains that allowance from [RFC3920] for the purpose of backward compatibility. Implementations are advised that using a prefix other than 'stream' for the stream namespace might result in interoperability problems. If an entity receives a stream header with a stream namespace prefix it does not accept, it MUST close the stream with a stream error, which SHOULD be <bad-namespace-prefix/> (Section, although some existing implementations send <bad-format/> (Section instead.

  74. jonas’

    so you might face implementations which close your stream with <bad-namespace-prefix/> if you do that, however, I found that they may not do that and instead misbehave

  75. rion has left

  76. rion has joined

  77. Жокир has joined

  78. Marc has joined

  79. pulkomandy has left

  80. pulkomandy has joined

  81. debacle has joined

  82. asterix has left

  83. asterix has joined

  84. asterix has left

  85. asterix has joined

  86. ali has joined

  87. ali has left

  88. Marc has left

  89. Жокир has left

  90. asterix has left

  91. asterix has joined

  92. asterix has left

  93. asterix has joined

  94. Жокир has joined

  95. pulkomandy has left

  96. pulkomandy has joined

  97. Marc has joined

  98. Marc has left

  99. Marc has joined

  100. flow

    jonas’, that section seems to talk only about the stream namespace prefix, not about additional namespace prefixes.

  101. jonas’


  102. jonas’


  103. jonas’

    wrong section

  104. flow

    Жокир, I'd also expect that to be fragile, but we could add add a stream feature indicating support for this

  105. jonas’

    I’m pretty sure that there was wording which discouraged or forbid usage of stream-level prefixes inside stanzas. And I’m also pretty sure that there was wording which discouraged use of stream-level prefixes altogether.

  106. jonas’

    but I can’t find either

  107. jonas’

    nevertheless, in practice, I’ve had issues with declaring namespace prefixes anywhere

  108. pep.

    https://xmpp.org/extensions/xep-0044.html flow

  109. jonas’

    you’ve got my attention

  110. pep.

    jonas’ too.

  111. jonas’

    > An implementation will need to maintain some sort of mapping between prefixes and namespaces, though some parsers, such as recent versions of Expat, can do this for the implementor.

  112. jonas’

    oh my god, those must’ve been grim times

  113. jonas’

    I’ll ask council to give me authorship of that thing

  114. jonas’

    I want to clean it up and give it a stream feature and bring it to Draft

  115. pep.

    \o/ our saviour

  116. pep.

    is stream features enough? would that be so that you start a new stream knowing about it?

  117. pep.

    or continue in the same stream with it?

  118. MattJ

    TIL about XEP-0044

  119. jonas’

    pep., a client could abort the stream if the server doesn’t advertise it

  120. jonas’

    *declaring* namespace prefixes on <stream:stream/> has typically not been an issue, but using them leads to fun behaviour

  121. pep.


  122. goffi has left

  123. pulkomandy has left

  124. pulkomandy has joined

  125. goffi has joined

  126. Жокир has left

  127. Жокир has joined

  128. Жокир has left

  129. Жокир has joined

  130. pulkomandy has left

  131. pulkomandy has joined

  132. Жокир has left

  133. Жокир has joined

  134. kikuchiyo has joined

  135. rion has left

  136. rion has joined

  137. Жокир has left

  138. Жокир has joined

  139. Жокир has left

  140. Жокир has joined

  141. Жокир has left

  142. Жокир has joined

  143. kikuchiyo has left

  144. kikuchiyo has joined

  145. kikuchiyo has left

  146. pulkomandy has left

  147. Жокир has left

  148. Жокир has joined

  149. pulkomandy has joined

  150. pulkomandy has left

  151. pulkomandy has joined

  152. flow

    I even think there is no need to abort the stream/connection: implementations could just fallback to the default behavior and pretend that they never declared the namespace prefixes

  153. flow

    and kudos to pep for digging out xep44 :)

  154. lovetox

    it does not matter how long you are in this community, there is always one more XEP you didnt know about

  155. jonas’

    flow, more annoying to implement though ;)

  156. flow

    jonas’, actually I was just thinking about how to do it in smack, and at least here I don't think it would be that of an issue. The XML serialize already has knowledege about an xml environment which also holds the active namespace prefixes, so it's just a matter of zapping those again, if the server does not announce support for them

  157. jonas’

    flow, in aioxmpp, it’d be a compile-time constant effectively. or a lot more code and slowness to include an optional "normaliser" at the serialisation level

  158. jonas’

    hm, ok, zapping those is an interesting approach

  159. pep.

    flow, fwiw larma told me about it

  160. pep.

    credits where it's due

  161. pep.


  162. flow

    pep., deleting them again from the xml environment

  163. flow

    like they where never added in the first place

  164. jonas’

    that should actually work without much overhead

  165. pep.

    If you intend to "zap" these namespaces then it means you have some kind of check in place to see if they're being used. So you'd have to check as long as your program runs. If you then zap them, you'd have to check that they're being zapped first

  166. Жокир has left

  167. flow

    pep., I am confused, but I also think that this is not the case. Take Жокир example with SM: assume the SM namespace has been declared as prefix in <stream/>, if now the server does not support it, smack will just fallback to do what it already does

  168. flow

    if the support announces support for it, then the serialize will emit <sm:r/>

  169. flow

    if the support announces support for it, then the serializer will emit <sm:r/>

  170. pep.

    Emitting is fine yes, I'm talking about reading

  171. flow

    ahh reading is a good point, a stream feature may not be enough in the c2s case, clients may want to tell the server that they support this

  172. pep.

    When receiving a stanza, if it's possible to have both, then I have to try both

  173. flow

    but in reading the situation is similar

  174. jonas’

    pep., no, you don’t have to "try"

  175. flow

    pep., what is "both" here?

  176. jonas’

    it’s unambiguous which serialisation variant is used and your XML parser will deal with it (if it supports it) and blow up otherwise

  177. asterix has left

  178. flow

    actually a full prefix aware parser should not blow up if you redundantly state the namespaces again

  179. pep.

    jonas’, ah wait, for some reason I had in mind that the namespaces themselves would change. Let me redo the maths with this info

  180. flow

    anyhow, I think there is maybe a reason why we do not see widespread adoption of xep44: may parsers do not carry around the full context of the document

  181. pep.

    flow, yeah and maybe they should :x

  182. flow

    Android XmlPullParser doesn't, and I wouldn't be suprised if Java's stax parser doesn't do also

  183. jonas’

    is there no namespace-compliant parser in android? O_o

  184. jonas’

    i.e. a thing which always gives you (namespace, local_name) instead of a qname?

  185. pulkomandy has left

  186. flow

    I always read a qname as a namespace and a localpart (localname)

  187. flow

    No the issue is that the parser would give you the localpart and the prefix

  188. jonas’

    qname is prefix:localname, at least in my glossary

  189. jonas’


  190. jonas’

    I hate those paresrs

  191. jonas’

    we should all burn them

  192. pulkomandy has joined

  193. flow

    well I read qname as the thing that fully qualifies the name, so either a local-name and a namespace, or the triple of local-name, prefix, and the prefix-matching namespace

  194. jonas’

    right, so, let me clarify:

  195. flow

    anyhow, if the prefix is not declared within the same element, you may not get the namespace with some parsers

  196. jonas’

    parsers which do not expose (namespace, local-name) tuples hassle-free everywhere and instead give you prefix+local-name shall burn in hell

  197. jonas’

    the fuck what

  198. jonas’


  199. pep.

    yeah there's no reason the application sees prefixes, it doesn't need them. Now that's a bit more complex because of us not doing 0044 already but..

  200. jonas’

    pep., actually, you need prefixes in some XML applications such as SOAP

  201. moparisthebest

    Json doesn't have namespaces therefore nothing needs them ever, if you are following along

  202. flow

    jonas’, interesting, why do you *need* them?

  203. pep.

    Well you also need them in XMPP. If 0044 had been a thing from the start we wouldn't have. If people had fully supported namespaces we wouldn't have needed them.

  204. jonas’

    flow, because they use prefixes in character data :(

  205. flow

    jonas’, interesting, why do you *need* them in SOAP?

  206. pep.

    Now we do, because we'll need to pass the info down to the XML parser at runtime

  207. jonas’

    pep., incorrect, RFC 6120 ties the usage of namespaces down enough to not need them

  208. jonas’

    you don’t need to know that the `stream:` prefix is used; the namespace is authoritative.

  209. jonas’

    but you should use the `stream:` prefix for compat reasons

  210. moparisthebest

    But yea I've dealt with various XML impls in Java that all seem to handle namespaces differently, or not at all, it's a bit of a nightmare

  211. pep.

    Right so in a way you do

  212. jonas’

    pep., why?

  213. pep.

    What you just said, compat

  214. jonas’

    just for the initial declaration

  215. jonas’

    but that’s not for parsing, but for serialisation

  216. pep.

    Sure, that still means the application knows

  217. jonas’

    yeah, that’s true

  218. jonas’

    I was specifically talking about parsing though

  219. pep.


  220. jonas’

    serialisation is different, because you normally *want* to pass information about prefixes to the serialiser

  221. jonas’

    the application knows better than the serialiser about which namespaces should be declared

  222. jonas’

    (e.g. declaring the stream-management namespace on the stream:stream element, a serialiser can never guess that you’ll use that namespace often)

  223. jonas’

    since declaring namespace prefixes is essentially an optimisation (unless you do namespaced attributes, where they’re required)

  224. pulkomandy has left

  225. pulkomandy has joined

  226. Marc has left

  227. flow

    FYI, moparisthebest, stax appears to be fine

  228. flow

    moparisthebest, http://paste.debian.net/1131699/

  229. moparisthebest

    flow: https://github.com/moparisthebest/sxf4j 2012 looks like the last time I tried it, I think maybe half of those backends are unmaintained now...

  230. flow

    moparisthebest, yeah, I think StAX's introduction in Java 8 helped here a lot

  231. flow

    which was ~2014

  232. moparisthebest

    This was with java6 too, seems like the dark ages now :)

  233. jonas’

    it sure sounds like dark ages

  234. flow

    So for Smack, I am probably going to support XPP3 for the next for years. Ideally the Android Platform would then provide the StAX API (after google moved a bit $$$ towards oracle potentially). Otherwhise one has to bundle another xml parser library for Smack on Android if I ever drop support for XPP3

  235. flow

    So for Smack, I am probably going to support XPP3 for the next few years. Ideally the Android Platform would then provide the StAX API (after google moved a bit $$$ towards oracle potentially). Otherwhise one has to bundle another xml parser library for Smack on Android if I ever drop support for XPP3

  236. flow

    I also could introduce namespace awareness in Smack's XPP3 compatiblity layer, hmmm

  237. paul has left

  238. Marc has joined

  239. pulkomandy has left

  240. pulkomandy has joined

  241. paul has joined

  242. paul has left

  243. paul has joined

  244. paul has left

  245. paul has joined

  246. paul has left

  247. paul has joined

  248. paul has left

  249. paul has joined

  250. pulkomandy has left

  251. pulkomandy has joined

  252. pulkomandy has left

  253. pulkomandy has joined

  254. pulkomandy has left

  255. pulkomandy has joined

  256. asterix has joined

  257. Marc has left

  258. Martin has left

  259. Martin has joined

  260. pulkomandy has left

  261. Marc has joined

  262. pulkomandy has joined

  263. goffi has left

  264. pulkomandy has left

  265. pulkomandy has joined

  266. paul has left

  267. pulkomandy has left

  268. pulkomandy has joined

  269. goffi has joined

  270. Zash has left

  271. Zash has joined

  272. kikuchiyo has joined

  273. asterix has left

  274. pulkomandy has left

  275. pulkomandy has joined

  276. pulkomandy has left

  277. pulkomandy has joined

  278. kikuchiyo has left

  279. kikuchiyo has joined

  280. Жокир has joined

  281. kikuchiyo has left

  282. kikuchiyo has joined

  283. Жокир has left

  284. Жокир has joined

  285. Martin has left

  286. Martin has joined

  287. goffi has left

  288. Жокир

    There isn't a single xep involving ns prefixes with attributes, is there? Can this xml feature be safely ignored then?

  289. Жокир has left

  290. Жокир has joined

  291. pulkomandy has left

  292. kikuchiyo has left

  293. pulkomandy has joined

  294. pulkomandy has left

  295. pulkomandy has joined