jdev - 2021-08-06


  1. marc0s has left
  2. marc0s has joined
  3. mikeye has joined
  4. mikeye has left
  5. debacle has left
  6. marc0s has left
  7. marc0s has joined
  8. mac has left
  9. Squeaky Latex Folf has left
  10. alexbay218 has joined
  11. ian has joined
  12. ian has left
  13. Squeaky Latex Folf has joined
  14. Squeaky Latex Folf has left
  15. Squeaky Latex Folf has joined
  16. Squeaky Latex Folf has left
  17. Squeaky Latex Folf has joined
  18. Squeaky Latex Folf has left
  19. Squeaky Latex Folf has joined
  20. nephele has joined
  21. Squeaky Latex Folf has left
  22. alexbay218 has left
  23. dezant has joined
  24. Squeaky Latex Folf has joined
  25. mac has joined
  26. Squeaky Latex Folf has left
  27. mikeye has joined
  28. Squeaky Latex Folf has joined
  29. pasdesushi has left
  30. scorch has left
  31. Squeaky Latex Folf has left
  32. mikeye has left
  33. Squeaky Latex Folf has joined
  34. scorch has joined
  35. Squeaky Latex Folf has left
  36. Yagizа has joined
  37. Squeaky Latex Folf has joined
  38. nephele has left
  39. Kev has left
  40. Kev has joined
  41. Squeaky Latex Folf has left
  42. alexbay218 has joined
  43. jgart has joined
  44. nephele has joined
  45. kikuchiyo has left
  46. Squeaky Latex Folf has joined
  47. DebXWoody has joined
  48. DebXWoody has left
  49. mikeye has joined
  50. marc0s has left
  51. marc0s has joined
  52. kikuchiyo has joined
  53. Squeaky Latex Folf has left
  54. mikeye has left
  55. kikuchiyo has left
  56. Squeaky Latex Folf has joined
  57. nephele has left
  58. Squeaky Latex Folf has left
  59. Squeaky Latex Folf has joined
  60. raghavgururajan has joined
  61. Wojtek has left
  62. Squeaky Latex Folf has left
  63. kikuchiyo has joined
  64. emus has joined
  65. Squeaky Latex Folf has joined
  66. Squeaky Latex Folf has left
  67. kikuchiyo has left
  68. kikuchiyo has joined
  69. Squeaky Latex Folf has joined
  70. Squeaky Latex Folf has left
  71. _Liveware Problem_ has joined
  72. Squeaky Latex Folf has joined
  73. Kev has left
  74. Kev has joined
  75. Squeaky Latex Folf has left
  76. Squeaky Latex Folf has joined
  77. jgart has left
  78. Squeaky Latex Folf has left
  79. jgart has joined
  80. Squeaky Latex Folf has joined
  81. goffi has joined
  82. mac has left
  83. me9 has joined
  84. Squeaky Latex Folf has left
  85. mikeye has joined
  86. Alex has joined
  87. goffi has left
  88. goffi has joined
  89. Squeaky Latex Folf has joined
  90. xecks has left
  91. mikeye has left
  92. mikeye has joined
  93. Squeaky Latex Folf has left
  94. sth has joined
  95. Squeaky Latex Folf has joined
  96. goffi has left
  97. xecks has joined
  98. alexbay218 has left
  99. Squeaky Latex Folf has left
  100. pasdesushi has joined
  101. goffi has joined
  102. Squeaky Latex Folf has joined
  103. debacle has joined
  104. sth has left
  105. Squeaky Latex Folf has left
  106. Squeaky Latex Folf has joined
  107. Wojtek has joined
  108. Squeaky Latex Folf has left
  109. Squeaky Latex Folf has joined
  110. Squeaky Latex Folf has left
  111. Alex has left
  112. Alex has joined
  113. scorch has left
  114. Squeaky Latex Folf has joined
  115. mikeye has left
  116. Squeaky Latex Folf has left
  117. Squeaky Latex Folf has joined
  118. jgart has left
  119. Squeaky Latex Folf has left
  120. Squeaky Latex Folf has joined
  121. Squeaky Latex Folf has left
  122. debacle has left
  123. Squeaky Latex Folf has joined
  124. debacle has joined
  125. nephele has joined
  126. jgart has joined
  127. goffi has left
  128. nephele has left
  129. lovetox has left
  130. marc0s has left
  131. marc0s has joined
  132. scorch has joined
  133. scorch has left
  134. lovetox has joined
  135. amit has joined
  136. amit hello @all . Can i use XMPP protocol in django with asgi ?
  137. jonas’ django is python, python is turing complete, yes you can.
  138. amit Need any library like aioxmpp or only xmpp protocol like ws?
  139. scorch has joined
  140. Sam If you're asking for some kind of pre-built integration I don't think there is any, you'd have to build it yourself (probably using a library like aioxmpp)
  141. Sam Are you just wanting to display a client on a webpage though? That doesn't have much to do with django specifically and will be more or less the same for anything
  142. amit Actually i am looking an alternative of websocket. In websocket a server can accept max 65535 connection simultaneously and its very expensive. My requirement is to implement instant chat app.
  143. scorch has left
  144. scorch has joined
  145. flow amit, huh websockets can only accept 2^16 connections? I somehow doubt this
  146. Kev has left
  147. Kev has joined
  148. amit for each connection it occupy one port number
  149. Sam That's not how websockets work, maybe you're mixing up websockets with regular sockets?
  150. Sam I'm not really sure what you're asking for though, maybe you could explain a bit more about the project and what your needs are and it would help us help you better? This doesn't sound like a django or even XMPP specific question anymore to me, but it's hard to tell.
  151. kikuchiyo has left
  152. nephele has joined
  153. kikuchiyo has joined
  154. nephele has left
  155. amit has left
  156. nephele has joined
  157. jonas’ that's also not how regular sockets work by the way
  158. jonas’ a TCP connection is defined by (src-addr, src-port, dst-addr, dst-port). in a server, dst-port and dst-addr are typically constant (e.g. 192.0.2.1:443 or 192.0.2.1:5222).
  159. jonas’ so you only need a single address+port for a server socket and the clients are identified by their address + port
  160. jonas’ likewise, for a client, you can reuse the same source port as long as you are connecting to different destination ports + addresses
  161. jonas’ so that "at most 65535 connections because of ports" limit is bogus
  162. jonas’ for UDP, things are a bit different because it is inherently connectionless, there you might have more constraints depending on the protocol running on top of it. Stuff like QUIC has a connection ID though by which it multiplexes, so there it matters even less.
  163. goffi has joined
  164. lovetox has left
  165. lovetox has joined
  166. goffi has left
  167. marc0s has left
  168. marc0s has joined
  169. Alex has left
  170. Alex has joined
  171. oibalos has left
  172. jgart has left
  173. selurvedu has left
  174. Wojtek has left
  175. gav has joined
  176. Sam I always forget that MUC needs PEP for bookmarks and PEP needs disco if you want to receive updates. Guess I have my work cut out for me :(
  177. Sam really hasn't figured out a good way to do disco in particular
  178. nephele has left
  179. nephele has joined
  180. sonny has left
  181. sonny has joined
  182. sonny has left
  183. sonny has joined
  184. MattJ What are you struggling with?
  185. lovetox has left
  186. Sam A mix of motivation to read several giant XEPs that are all needed in some part to make this work, and with disco in particular I just haven't found a nice API that doesn't make it hard to use (eg. I shouldn't have to register a handler with the client *and* a disco feature, I should just be able to have the handler know what features exist and be able to also respond to disco… this isn't hard, I just haven't found a good way to do it in my own codebase)
  187. Sam The disco stuff is all super project specific, unfortunately
  188. nephele has left
  189. MattJ I've been fairly happy with the disco API in Verse, not that I've used it much recently
  190. MattJ Main thing that tripped me up was the concept of "nodes", which I have to confess I'm still not sure I understand :)
  191. MattJ There are two aspects to a disco API, the discovery side and the advertisement side
  192. Sam Indeed; I think I've got all that working fine from the perspective of someone querying for disco info, nodes work, you can walk the tree, etc. (https://pkg.go.dev/mellium.im/xmpp/disco@main), but the advertisement side I've been stuck on for ages for some reason
  193. Sam I haven't seen Verse before I don't think, I'll look up what you do there; thanks
  194. MattJ That's mostly just a local registry, right?
  195. MattJ per node
  196. Sam Yah, so you end up with a tree-like structure of nodes.
  197. MattJ "of nodes" - sure? Disco info/items doesn't actually allow you to discover nodes, right?
  198. MattJ You have to know what node you want to query
  199. lovetox has joined
  200. Kev Disco is not a hierachy of nodes, FWIW.
  201. Sam Right, so you start from the root node (empty node name) and then you can query over all those, etc. to walk the tree
  202. MattJ Tree of JIDs, not nodes
  203. Kev It’s a flat pool of nodes. You can construct the node names as you wish so they encode structure within them, but don’t have to, and the structure is by appearance only.
  204. Sam I guess, but since you can't discover all nodes except by querying root, then querying those nodes, it's effectively a tree
  205. Sam At least, it has to be walked like a tree if you want to find all nodes
  206. Kev You can’t query the root to find all nodes for disco.
  207. Sam Right, you can only find the nodes directly under the root node
  208. MattJ Ah, there is a 'node' attribute for items
  209. Kev You can’t even do that.
  210. MattJ Shown in https://xmpp.org/extensions/xep-0030.html#example-17
  211. Sam I guess after all this time I still don't understand disco then
  212. Sam Or am I thinking of Items and you're thinking of Info? I guess I need to go re-read this for the milionth time
  213. Kev You can have results that include lists of other jids and nodes, so you *can* build a tree, and if you want to build a tree, what you describe is right.
  214. Kev But you don’t have to build a tree, you don’t have to list different nodes under the root, etc.
  215. Sam Oh sure, I mean, I know that you can address any node directly without querying for the top level ones or knowing their name first or whatever
  216. Kev My client (kev@server/res ) could have a ‘kevstuff’ node if it wanted, and that needn’t be listed anywhere.
  217. Kev So the only way you’d know it existed was if you queried it and did or didn’t get a result.
  218. Sam oooh, that's fair too and I hadn't thought of it.
  219. Kev So if your disco responder model relies on tree representation that’s fine and up to you, but it doesn’t cover all the disco uses.
  220. Sam That's a great API consideration that I hadn't worked out, thank you
  221. Sam (still, I find it helpful from the querying entities perspective to provide functionality to walk the nodes like a tree; makes it easy to design browsers like Gajim has, for example, but it's a good point that I shouldn't rely on it)
  222. Kev Personally, I would just register a disco items or info callback or callbacks that gets passed the JID and Node, and then returns a set of results that are concatenated to form a result for the response.
  223. Kev And I wouldn’t in the XMPP Library API do any sort of imposition of structure. Let the application sort it out, only the application knows what it wants.
  224. Kev Yes, having a tree walker in the library for queries is a sometimes useful thing.
  225. Kev We do that for Swift for finding MUCs.
  226. Kev I note that’s walking the JID tree rather than a node tree, mind.
  227. Sam Just having a way to let the application sort it out is fine I guess, but if they've already created a handler for MUC (for example) and passed that into the router that handles XML and pushes it to the right place, it seems like they should be able to say "just use the disco for all the handlers we have registered" and not have to go back and figure them all out
  228. Sam To prevent eg. registering the handler for MUC but then forgetting to register the disco node
  229. Sam err, yes, JID tree for items I guess
  230. Kev Within M-Link we do that, yes. When we register handlers (delegates in our terms), those delegates will be called for append disco results when the router’s queried.
  231. Kev Which is basically > Personally, I would just register a disco items or info callback or callbacks that gets passed the JID and Node, and then returns a set of results that are concatenated to form a result for the response. with the registering being automatic.
  232. Sam yah, it's the automatic part I need to figure out a clean way to do
  233. Sam Really it's an issue with my previous design decisions (I think, kind of making this up as I think outloud). I have a router that you register handlers against to handle certain XML elements. I would expect disco responses to be one of those handlersr. However, the handlers don't have access to the router they're registered on, so how does it know what else has been registered?
  234. Kev Disco has to be a special case.
  235. Sam I think it might, yes. Built into the router or something.
  236. Sam I really hate to do that though; I feel like there's got to be a nice way to make it work without it.
  237. Sam Generally speaking I feel like it it has to be a special case either the underlying spec (nothing I can do) or my API (hopefully I can fix it) has a rather fundamental structural problem. Figuring out which and what to do about it is time consuming and hard though.
  238. gav has left
  239. goffi has joined
  240. Kev I’ve not had a significant problem working disco into any of the codebases I’ve done so, so I don’t *think* the spec is fundamentally broken.
  241. xecks has left
  242. xecks has joined
  243. Sam Oh yah, it's almost certainly not
  244. raghavgururajan has left
  245. goffi has left
  246. goffi has joined
  247. selurvedu has joined
  248. goffi has left
  249. goffi has joined
  250. goffi has left
  251. goffi has joined
  252. x51 has joined
  253. nephele has joined
  254. DebXWoody has joined
  255. goffi has left
  256. nephele has left
  257. Vaulor has left
  258. Vaulor has joined
  259. nephele has joined
  260. mac has joined
  261. nephele has left
  262. x51 has left
  263. nephele has joined
  264. Kev has left
  265. raghavgururajan has joined
  266. mac has left
  267. wancat has left
  268. debacle has left
  269. goffi has joined
  270. kikuchiyo has left
  271. Wojtek has joined
  272. mac has joined
  273. kikuchiyo has joined
  274. eta has left
  275. eta has joined
  276. debacle has joined
  277. dezant has left
  278. alexbay218 has joined
  279. raghavgururajan has left
  280. raghavgururajan has joined
  281. mac has left
  282. sonny has left
  283. sonny has joined
  284. Vaulor has left
  285. sonny has left
  286. sonny has joined
  287. Vaulor has joined
  288. Wojtek has left
  289. dezant has joined
  290. nephele has left
  291. nephele has joined
  292. Sam Oh hey, apparently I came up with an elegant (if I do say so myself) way to handle disco, made a branch, and then forgot about it. Glad I looked before starting over on the thing I was talking about earlier.
  293. dezant has left
  294. dezant has joined
  295. moparisthebest protip: always check git stash
  296. moparisthebest maybe un-needed if you have a better memory...
  297. Sam Not I…
  298. me9 has left
  299. mac has joined
  300. nephele has left
  301. me9 has joined
  302. sonny has left
  303. sonny has joined
  304. disgyze has left
  305. DebXWoody has left
  306. Yagizа has left
  307. DebXWoody has joined
  308. mig has joined
  309. mig has left
  310. mig has joined
  311. mig has left
  312. mig has joined
  313. goffi has left
  314. Alex has left
  315. Alex has joined
  316. marc0s has left
  317. sonny has left
  318. sonny has joined
  319. marc0s has joined
  320. Vaulor has left
  321. Vaulor has joined
  322. Link Mauve “14:59:22 Sam> I always forget that MUC needs PEP for bookmarks […]”, for this part, it might be useful to read this, about the current mess that is bookmarks: https://docs.modernxmpp.org/client/groupchat/#bookmarks
  323. Sam :( good docs, thanks. I'll probably just implement the PEP ones. If we detect another client that doesn't advertise support and the server doesn't do the compat thing maybe I'll log a message telling them to change clients or ask their server admin for #compat.
  324. Alex has left
  325. Link Mauve Given the vast majority of clients do Private XML, and the Prosody modules can’t support both PEP versions (and I wouldn’t expect complete synchronisation to be easy to implement in other servers’ PEP modules either, but I’d love to be proven wrong), I don’t recommend implementing old PEP at all any more.
  326. Link Mauve Private XML is the better fallback.
  327. mac has left
  328. mac has joined
  329. me9 has left
  330. Sam Sorry, I meant just the new PEP one, singular
  331. debacle has left
  332. _Liveware Problem_ has left
  333. scorch has left
  334. scorch has joined
  335. marc0s has left
  336. marc0s has joined
  337. selurvedu has left
  338. selurvedu has joined