jdev - 2021-12-24


  1. glickyong has left
  2. defanor has left
  3. atomicwatch has left
  4. marc0s has left
  5. marc0s has joined
  6. msavoritias has left
  7. marc0s has left
  8. marc0s has joined
  9. glickyong has joined
  10. marc0s has left
  11. marc0s has joined
  12. marc0s has left
  13. marc0s has joined
  14. marc0s has left
  15. marc0s has joined
  16. emus has left
  17. jgart has left
  18. debacle has left
  19. marc0s has left
  20. marc0s has joined
  21. glickyong has left
  22. FireFly has left
  23. glickyong has joined
  24. sonny has left
  25. glickyong has left
  26. glickyong has joined
  27. mac has joined
  28. jgart has joined
  29. mac has left
  30. marc0s has left
  31. marc0s has joined
  32. glickyong has left
  33. Yagizа has joined
  34. mac has joined
  35. contrapunctus 😄
  36. kikuchiyo has left
  37. Alex has left
  38. wurstsalat has left
  39. rafasaurus has left
  40. rafasaurus has joined
  41. Жокир has joined
  42. Жокир Xmpp makes heavy use of namespaces, but are they in reality all that significant? I mean, are there actually any elements defined by existing standards that have different namespaces but same names?
  43. mac has left
  44. Yagizа has left
  45. defanor has joined
  46. Alacer_dsrt has joined
  47. mac has joined
  48. emus has joined
  49. jonas’ Жокир, <query/>, in about every standard using IQs
  50. jonas’ there's also <body xmlns="jabber:client"/> vs. <body xmlns="http://www.w3.org/1999/xhtml"/>
  51. COM8 has joined
  52. atomicwatch has joined
  53. COM8 has left
  54. COM8 has joined
  55. COM8 has left
  56. nephele has joined
  57. Yagizа has joined
  58. glickyong has joined
  59. atomicwatch has left
  60. Yagizа has left
  61. atomicwatch has joined
  62. paul has joined
  63. atomicwatch has left
  64. atomicwatch has joined
  65. wurstsalat has joined
  66. marmistrz has joined
  67. Neustradamus has left
  68. Neustradamus has joined
  69. Martin has left
  70. Martin has joined
  71. FireFly has joined
  72. huhn has left
  73. emus has left
  74. emus has joined
  75. Alex has joined
  76. atomicwatch has left
  77. atomicwatch has joined
  78. debacle has joined
  79. sonny has joined
  80. moparisthebest has left
  81. marmistrz has left
  82. flow Жокир, not only XMPP does use namespaces, but XML parser do too
  83. flow and name clashes are a thing, even though they are usually mostly encountered in large projects, while namespaces are an easy way to solve it
  84. msavoritias has joined
  85. Жокир I know they are a thing in theory, I was asking about xmpp practice. But I've already been told they indeed are a thing there. Damn those thing add a level a complexity, as if streaming xml wasn't complicated enough
  86. Жокир And lots of bandwidth
  87. moparisthebest has joined
  88. mac has left
  89. doge has left
  90. doge has joined
  91. MattJ News to me that some short text strings are "lots of bandwidth" 🙂
  92. Yagizа has joined
  93. MattJ XMPP implementations would be a horrible mess without namespaces
  94. mac has joined
  95. Жокир Well, compared to the contents itself they certailnly are. Like in <a xmlns='urn:xmpp:sm:3' h='1'/> meaningful characetrs here are basically "a" and "1". That's two characters. Thanks to xml, and thanks even more to the brilliant idea to send the namespace with every ack, the proportion of meaningful data to xml details is 2:29. Which is about 7%
  96. Жокир And that's a namespace that at least doesn't include "https://..." like some others do
  97. selurvedu > meaningful characetrs here are basically "a" and "1" um... I am not even going to try to explain why there's much more to it than you say.
  98. jgart has left
  99. Жокир With s exps this could be smth like (a 1) Even with xml this could at least boild down to <a h='1'/>, three times shorter
  100. selurvedu Also, see how WhatsApp having similar concerns managed to compress XML in their proprietary FunXMPP protocol https://sci-hub.se/10.1016/j.diin.2015.09.002
  101. contrapunctus Жокир: s-expressions FTW 🙂
  102. pulkomandy there is stream compression defined in XMPP or apparently you can use compression at the TLS level (according to https://xmpp.org/extensions/xep-0138.html), I would say that the very repetitive parts of XML will compress very well with that
  103. jgart has joined
  104. Жокир Of course you can *manage* to compress it. But no popular client does. You can *manage* any kind of bloat.
  105. Жокир if you have enough time and resources
  106. pulkomandy or you can remove the X in XMPP and make it a non-extensible protocol. Then you can remove a lot of things form it :)
  107. Жокир Extensiblity doesn't mean bloat
  108. Жокир if it weren't for the readily existing code, <a h='1'/> could work just as well
  109. contrapunctus .o(It's probably not too difficult to define an s-expression encoding for XML (since this can vary between XML libraries), and have XMPP-over-sexp. Probably be easy to use it too - server can decide what to use based on what the client sends.)
  110. selurvedu Жокир, do you have some specific need for saving traffic? I find XMPP using just tiny bits of traffic compared to many modern messengers and other apps. Of course, enterprise usage and server owners will use more traffic...
  111. selurvedu Жокир, you don't have to include namespaces with every single element. It's not that problematic as you describe it. https://xmpp.org/rfcs/rfc6120.html#streams-ns Also some other people actually don't like namespaces as well, it's been discussed (see here https://wiki.xmpp.org/web/XMPP_Office_Hours/2021-04-13-Notes )
  112. Жокир >compared to modern messengers and other apps That's not saying much is it 🙂 Saying "lighter than modern apps" is like saying "cleaner than sewage" No, I don't have any specific requirements for saving traffic. Instead I'm evaluating xmpp among other protocols and wondering maybe there's a rationalization to ascpects I find irrational. >you don't have to include namespaces with every single element. It's not that problematic as you describe it. https://xmpp.org/rfcs/rfc6120.html#streams-ns Heard about that, also heard that lots of software doesn't support it 🙂 Another example of how one *can* in principle manage bloat, but that doesn't mean you will
  113. defanor contrapunctus, IME encoding XML in s-expressions (as in SXML and/or Emacs's xml.el) becomes perhaps more awkward than just using XML when you try to handle namespace prefixes and attribute namespaces.
  114. contrapunctus defanor: do tell...what happens?
  115. defanor contrapunctus, well, you have lots of s-expressions. A lot of nesting, I find it harder to read and write than XML.
  116. defanor Not like the s-expressions you'd normally compose, if you've designed a protocol or an API for those in mind at once.
  117. defanor "With those in mind", even.
  118. selurvedu > Heard about that, also heard that lots of software doesn't support it 🙂 Dunno, works for me 🙃️
  119. glickyong has left
  120. Жокир has left
  121. al has joined
  122. flow Жокир I think if you have a text based protocol, than written out names make the protocol more accessible, even though it consumes more bytes on the wire. That's a similar argument when programming, in favor of self-explaining variable names, compared to single letter variables names. I doubt that those extra bytes on the wire kill your battery or will have you run into your traffic quota. That said, I did not measure it myself, but, as far as I can tell, most people complaining about the verbositiy of XMPP do so only based on their gut feeling. It would be really nice if we had some hard facts.
  123. flow Жокир, you may be happy to hear that "<a xmlns='urn:xmpp:sm:3' h='1'/>" could probably be easily shorted into "<a:sm h='1'>" if this particular feature of XML namespaces has been negotiated with the remote party
  124. contrapunctus defanor: pattern matching? 🤷
  125. Zash flow: just gotta xep that negotiation
  126. flow Zash, wanna give me a little christmas present? :)
  127. contrapunctus defanor: > contrapunctus, well, you have lots of s-expressions. A lot of nesting, I find it harder to read and write than XML. Oh wait, there are libraries to query the s-expressions!
  128. contrapunctus defanor: > contrapunctus, well, you have lots of s-expressions. A lot of nesting, I find it harder to read and write than XML. Oh wait, there are libraries to query the s-expression representations of XML!
  129. al has left
  130. defanor contrapunctus, pattern matching is awkward for XML, since order normally matters there (at least in generic ones for s-exps, like pcase), but not in XML, and IIRC parsers tend to preserve the order. Libraries for querying those structures would probably indeed be convenient, but that sounds similar to working with just some XML objects, not benefiting as much from those being encoded in s-expressions.
  131. defanor I mean the order of attributes and such, not child elements. Though the order of those matters in XML, but not always in XMPP.
  132. Zash flow: I don't christmas, sorry.
  133. defanor Hrm, though maybe even the order of attributes may matter in XML in general, but still not always in XMPP.
  134. defanor https://www.w3.org/TR/2008/REC-xml-20081126/#sec-starttags -- nope, the order of attributes indeed shouldn't be significant in general.
  135. me9 has joined
  136. flow yep, attribute order can not matter, since there can only be at most one attribute with a given name on an element
  137. flow element order, on the other hand, does matter in XML, but typically not in XMPP (there me be exceptions, but I don't have one at hand)
  138. marc0s has left
  139. marc0s has joined
  140. Wojtek has joined
  141. mac has left
  142. mac has joined
  143. contrapunctus defanor: I'd probably prefer it because easier on the eyes, compatible with standard list functions, less bytes to transfer, simpler for people to understand and for programs to parse...
  144. debacle has left
  145. doge flow: > Жокир I think if you have a text based protocol, than written out names make the protocol more accessible, even though it consumes more bytes on the wire. That's a similar argument when programming, in favor of self-explaining variable names, compared to single letter variables names. I doubt that those extra bytes on the wire kill your battery or will have you run into your traffic quota. That said, I did not measure it myself, but, as far as I can tell, most people complaining about the verbositiy of XMPP do so only based on their gut feeling. It would be really nice if we had some hard facts. I don't remember the quote exactly but Xml combines the readability of binary formats with the efficiency of plain text ones Xmpp streams are not human readable imho, at least not without heavy formatting. And frankly even in terms of efficiency even most plaintext formats easily beat xml. Take json, or even homebrewn formats like what freenet uses (fcp) And verbosity does not always mean readability. Sometimes it even precludes it. I'd consider the succinct python much more readable than the verbose java. And in the particular example of <a h='1'/>, specifying the xmlns='blahblah' does not improve readability one bit. It impairs it even beyond what xml has already done
  146. marc0s has left
  147. marc0s has joined
  148. marc0s has left
  149. marc0s has joined
  150. marc0s has left
  151. marc0s has joined
  152. contrapunctus So...are there any working implementations of group voice chat? 🤔
  153. Zash contrapunctus: yes
  154. Zash Or, working on at least
  155. Zash Dino and JSXC afaik
  156. contrapunctus Huh
  157. wurstsalat looks like dino group voice chats just landed in master
  158. contrapunctus Wow, I must try that.
  159. pasdesushi has left
  160. Wojtek has left
  161. emus yes, but it is still deactivated I think
  162. PapaTutuWawa has joined
  163. pasdesushi has joined
  164. defanor contrapunctus, it can be fewer bytes, but as composed by Emacs's (xml-parse-region nil nil nil nil t) in Emacs, your message as an s-expression is actually larger: https://paste.uberspace.net/emacs-xml-sexp.txt
  165. Жокир has joined
  166. mac has left
  167. mac has joined
  168. kikuchiyo has joined
  169. defanor Not that s-expressions are unsuitable for XML manipulation though, it's just that even though I like them too, by simply piling XML's data model on top of the s-expressions one, you end up dealing with both at once, which I didn't quite like even locally.
  170. inky has joined
  171. Zash Turns out XML is already a decent encoding of the XML data model. Who knew?
  172. Жокир not that the xml data model is a particularly decent one tho
  173. lovetox i love xml, its great, namespaces are perfect for extensibility
  174. Zash It's fine, not really a problem, not something I would qant to spend time arguing about. Especially not today.
  175. jgart has left
  176. jgart has joined
  177. me9 has left
  178. flow doge, I think that is true if you stare at raw XMPP XML, but pretty-printed XMPP XML is very readable IMHO. I can't tell you how much positive feedback I got from Smack users after Smack started pretty printing the XML in its debugger. I think that was for some people an eye opener
  179. defanor XML's verbosity and relative complexity used to bother me in the past, but then I've found myself agreeing with the common sentiment that it doesn't really matter: plenty of other things to worry/care about in a network protocol, often more important ones.
  180. mac has left
  181. mac has joined
  182. Zash I'd rather figure out how to send less stuff than smaller stuff
  183. flow furthermore, the subset of XML that XMPP uses is pretty sane, and, for what it provides, not that complex
  184. flow I sometimes wish that it would be possible to write </> but then again, if this is my main critique of XML, then i'd say it's pretty good designed
  185. debacle has joined
  186. Zash Make it an editor macro
  187. flow well, my idea was that it would be on the wire too :)
  188. flow in fact, I think it is already an editor macro…
  189. Sam The subset thing is part of the problem. If you have to jump through hoops to make it sane, lots of people won't jump through those hoops and things will break. I'm not entirely sure my library handles this correctly, for example, and I know there have been issues with others that don't.
  190. Link Mauve “11:47:07 flow> element order, on the other hand, does matter in XML, but typically not in XMPP (there me be exceptions, but I don't have one at hand)”, in XHTML-IM it is very much important to keep the order of children.
  191. flow thanks Link, that's actually a good example
  192. flow Sam, not sure about that. from the top of my head, the subset is mostly what most modern XML parsers accept per default, plus, no XML comments
  193. Alastair Hogge has left
  194. flow at least that is my impression
  195. doge > “11:47:07 flow> element order, on the other hand, does matter in XML, but typically not in XMPP (there me be exceptions, but I don't have one at hand)” It doesn't mean the order is discarded does it Also yeah, xml carries more data than is actually used by xmpp. Such as element tails, element order
  196. Link Mauve When I wrote my first XMPP client, in high school, I did it by reverse engineering the XML logs of Gajim instead of reading the specification, these were Englicrypted and would have been of no use to me.
  197. flow "Englicrypted", like that :)
  198. Link Mauve Gajim only added newlines between tags, and that was enough for me to successfully write my first XMPP client for the Nintendo DS. ^^
  199. flow Link Mauve, it appears you broke the cipher by now ;)
  200. doge And then there is the usual xml stunt of <key>value</key> <key v="value/> Or in clinical cases <entry key="key" value="value"/>
  201. Link Mauve Turns out, daily exposure for 15 years was enough for that. :D
  202. Link Mauve doge, what is the issue here?
  203. doge > Gajim only added newlines between tags, and that was enough for me to successfully write my first XMPP client for the Nintendo DS. ^^ What language did one write Nintendo DS programs in?
  204. Link Mauve I used C.
  205. Link Mauve I didn’t know C very well at the time, I was still afraid of pointers back then.
  206. flow doge, that's a matter of good XML (and, by extension, XMPP protocol) design. I think I spot bad design by now, but I fear I don't have compiled a list of guidelines (there are some guidelines on XML design on the web though)
  207. flow but then again, it is sometimes personal preference what the right thing to do is
  208. Link Mauve https://linkmauve.fr/dev/jabber8.3.5.tar.xz is the last version I worked on.
  209. Link Mauve It was the end of the winter break and I had to start school again, and the code was horrid so during the following holidays I couldn’t really get back to it.
  210. doge > And then there is the usual xml stunt of > <key>value</key> > <key v="value/> > Or in clinical cases > <entry key="key" value="value"/> Compared to Json: {'key': 'value'} Or tcl: {key value} It's more verbose and less readable.
  211. Link Mauve As a corollary of the earlier issue, this client’s source is Frencrypted. :p
  212. defanor I was about to say that those clinical cases aren't unique to XML: I saw JSON being used that way too. Sometimes even "key1"/"value1", "key2"/"value2", etc.
  213. flow doge, point taken, but that is due XML not having explicit support for dictionaries
  214. flow usually, but depending on the value, a good format is: <entry key='foo'>value</entry>
  215. flow I dont' think that this is a strong argument against XML, but maybe I am just to used to it
  216. doge > Compared to > Json: {'key': 'value'} > Or tcl: {key value} > It's more verbose and less readable. And carries superfluous info like the fact that the elements tag is empty, or well that it is one of the myriad of ways to write the same thing. Not just write differently, it'll be represented in the data model differently. While providing no advantages. That's a complexity for the sake of complexity
  217. Link Mauve This is all good, until you need multiple values, or i18n, or…
  218. mac has left
  219. Link Mauve See XEP-0004 for a more forward-looking way of encoding a dict.
  220. doge > usually, but depending on the value, a good format is: <entry key='foo'>value</entry> Super verbose and not readable, wasting space and traffic. Just like all xml <entry key='foo'>value</entry> is harder to read than {key value} And MUCH longer to write
  221. Link Mauve doge, feel free to use XEP-0335.
  222. Zash Mmmmmmmmod_rest?
  223. Link Mauve Or that.
  224. doge Link Mauve: that unfortunately won't fix the fact that writing an xmpp client has to start with writing short of an xml parser
  225. rafasaurus has left
  226. Link Mauve Right, unless like Zash said you use mod_rest. :)
  227. jgart has left
  228. Жокир has left
  229. mac has joined
  230. pep. I guess the only XML parser that you'd need to write only needs to go up until <features/>, then you can do whatever serialization format you want :)
  231. flow or unless you simply use an parser from one of the various existing xml libraries
  232. flow or unless you simply use a parser from one of the various existing xml libraries
  233. flow but yeah, you probably have to or want to pre-process the XMPP stream before handing it over to your XML parser
  234. rafasaurus has joined
  235. pep. Is there a case where a pubsub node name is mandated, that isn't on PEP?
  236. sonny has left
  237. sonny has joined
  238. PapaTutuWawa has left
  239. Alastair Hogge has joined
  240. Alex has left
  241. Alex has joined
  242. inky has left
  243. inky has joined
  244. marmistrz has joined
  245. glickyong has joined
  246. moparisthebest has left
  247. pep. Not that many useful errors in PubSub :/
  248. marmistrz has left
  249. pep. "Node Configuration Not Supported", "Insufficient Privileges", "NodeID Required", "No Configuration Options", "Node Does Not Exist"
  250. pep. (For nodes)
  251. inky has left
  252. debacle has left
  253. moparisthebest has joined
  254. goffi has left
  255. Alastair Hogge has left
  256. atomicwatch has left
  257. me9 has joined
  258. atomicwatch has joined
  259. glickyong has left
  260. Alastair Hogge has joined
  261. mac has left
  262. mac has joined
  263. glickyong has joined
  264. emus has left
  265. Alex has left
  266. Alex has joined
  267. glickyong has left
  268. me9 has left
  269. me9 has joined
  270. pulkomandy has left
  271. pulkomandy has joined
  272. nephele has left
  273. goffi has joined
  274. stuart.j.mackintosh If XMPP were to become very popular in a short time, what implemented mechanisms (client or server as appropriate) exist now to manage spam and uninvited / unwelcome direct connection attempts?
  275. marc0s has left
  276. marc0s has joined
  277. mac has left
  278. mac has joined
  279. glickyong has joined
  280. me9 has left
  281. sonny has left
  282. sonny has joined
  283. sonny has left
  284. sonny has joined
  285. Martin https://github.com/JabberSPAM
  286. Martin There's a blacklist and in resources you found plenty modules for xmpp servers.
  287. lovetox has left
  288. stuart.j.mackintosh Thanks Martin
  289. lovetox has joined
  290. inky has joined
  291. rafasaurus has left
  292. glickyong has left
  293. larma has joined
  294. rafasaurus has joined
  295. Alacer has joined
  296. Alacer_dsrt has left
  297. Alacer_dsrt has joined
  298. Alacer_dsrt has left
  299. Alacer_dsrt has joined
  300. sonny has left
  301. Martin There's a blacklist and in resources you'll find plenty modules for xmpp servers.
  302. larma has left
  303. nephele has joined
  304. inky has left
  305. Alacer_dsrt has left
  306. marc0s has left
  307. marc0s has joined
  308. Alacer has left
  309. glickyong has joined
  310. alacer has joined
  311. rafasaurus has left
  312. alacer has left
  313. lovetox has left
  314. jgart has joined
  315. rafasaurus has joined
  316. antranigv has left
  317. lovetox has joined
  318. sonny has joined
  319. mac has left
  320. mac has joined
  321. Neustradamus has left
  322. mac has left
  323. mac has joined
  324. inky has joined
  325. moparisthebest has left
  326. pulkomandy has left
  327. pulkomandy has joined
  328. Ingolf has left
  329. pulkomandy has left
  330. pulkomandy has joined
  331. pulkomandy has left
  332. pulkomandy has joined
  333. Ingolf has joined
  334. marc0s has left
  335. marc0s has joined
  336. marc0s has left
  337. marc0s has joined
  338. nephele has left
  339. glickyong has left
  340. al has joined
  341. emus has joined
  342. antranigv has joined
  343. mac has left
  344. mac has joined
  345. Yagizа has left
  346. marc0s has left
  347. marc0s has joined
  348. PapaTutuWawa has joined
  349. debacle has joined
  350. mac has left
  351. mac has joined
  352. al has left
  353. inky has left
  354. dezant has joined
  355. mac has left
  356. Yagizа has joined
  357. emus has left
  358. bung has joined
  359. debacle has left
  360. bung has left
  361. inky has joined
  362. bung has joined
  363. bung has left
  364. Yagizа has left
  365. mac has joined
  366. inky has left
  367. msavoritias has left
  368. moparisthebest has joined
  369. inky has joined
  370. sonny has left
  371. sonny has joined
  372. sonny has left
  373. sonny has joined
  374. inky has left
  375. marc0s has left
  376. marc0s has joined
  377. antranigv has left
  378. marc0s has left
  379. marc0s has joined
  380. atomicwatch has left
  381. pep. Is there a way to know the room just got created when I join it?
  382. mac has left
  383. 9lakes has left
  384. antranigv has joined
  385. 9lakes has joined
  386. atomicwatch has joined
  387. marc0s has left
  388. marc0s has joined
  389. atomicwatch has left
  390. goffi has left
  391. dezant has left