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 4.9.3.2), although some existing implementations send <bad-format/> (Section 4.9.3.1) 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’ oh
  102. jonas’ right
  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. k
  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. "zapping"?
  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’ ugh
  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’ seriously?
  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. k
  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