XSF logo jdev - 2020-02-12


  1. Syndace has joined
  2. Marc has left
  3. Marc has joined
  4. pulkomandy has left
  5. pulkomandy has joined
  6. larma has left
  7. aj has joined
  8. aj has left
  9. asterix has joined
  10. Extarv has left
  11. Extarv has joined
  12. Extarv has left
  13. Extarv has joined
  14. pulkomandy has left
  15. kikuchiyo has joined
  16. moparisthebest has left
  17. moparisthebest has joined
  18. pulkomandy has joined
  19. Extarv has left
  20. Extarv has joined
  21. pulkomandy has left
  22. pulkomandy has joined
  23. Alex has left
  24. Alex has joined
  25. Syndace has left
  26. Syndace has joined
  27. debacle has left
  28. aj has joined
  29. aj has left
  30. pulkomandy has left
  31. pulkomandy has joined
  32. debacle has joined
  33. pulkomandy has left
  34. pulkomandy has joined
  35. Marc has left
  36. Marc has joined
  37. pulkomandy has left
  38. larma has joined
  39. pep. has left
  40. pep. has joined
  41. Extarv has left
  42. Extarv has joined
  43. kikuchiyo has left
  44. Extarv has left
  45. Extarv has joined
  46. pulkomandy has joined
  47. sonny has left
  48. sonny has joined
  49. MattJ has left
  50. MattJ has joined
  51. kikuchiyo has joined
  52. kikuchiyo has left
  53. pulkomandy has left
  54. kikuchiyo has joined
  55. pulkomandy has joined
  56. kikuchiyo has left
  57. rion has left
  58. rion has joined
  59. kikuchiyo has joined
  60. kikuchiyo has left
  61. pulkomandy has left
  62. pulkomandy has joined
  63. Marc has left
  64. Marc has joined
  65. Wojtek has joined
  66. kikuchiyo has joined
  67. pulkomandy has left
  68. pulkomandy has joined
  69. lovetox has joined
  70. Extarv has left
  71. Extarv has joined
  72. pulkomandy has left
  73. pulkomandy has joined
  74. sam has joined
  75. kikuchiyo has left
  76. Sam Whited has joined
  77. Sam Whited I feel like I've had this discussion a few times, but I never remember: if I get an IQ but don't recognize the local name (but do recognize the namespace) should I send back bad-request or feature-not-implemented? conversations.im (ejabberd, I think) sends back bad-request, which makes sense because it doesn't match the schema, but feature-not-implemented seems to overlap and be more specific. Maybe it doesn't matter at all?
  78. debacle has left
  79. Zash Sam Whited, your description is basically identical to the text description of feature-not-implemented, so, well, that might be suitable :)
  80. Sam Whited Seems more or less identical to the description of bad-request too though (it obviously doesn't match the schema for that particular namespace/feature), and that's what ejabberd returns so I was wondering if there's a reason
  81. Zash Prosody matches most iqs on the (name xmlns) tuple, then says service-unavailable if nothing handles it
  82. jonas’ I send back service-unavailable, because I don’t distinguish "knowing the namespace" vs. "knowing the namespace and the local-name"
  83. Sam Whited Oh geeze, a third one with overlap. That would be a lot easier actually, I had been planning on sending that back if the namespace wasn't recognized, so maybe I'll just send one error and call it a day.
  84. Sam Whited Doesn't sound like there's any weird compatibility issues with one vs another anyways, so I might as well start with service-unavailable and then if users complain I can add more fine grained error handling later
  85. sam has left
  86. Sam Whited has left
  87. SamWhited has left
  88. Zash I stumbled upon XEP-0045 saying that service-unavailable (and type=wait) means that the room "has reached its maximum number of occupants"
  89. Zash So, everything is a mess and nothing means anything, do whatever you want
  90. Sam Whited *sigh* that figures. Thanks for the help
  91. Sam Whited I can't imagine what the user would do with the knowledge that we do handle the namespace but not the localname anyways, so just having a generic error is probably good enough
  92. Zash Guess what Prosody says if an external Component isn't connected?
  93. Sam Whited service-unavailable type='cancel'?
  94. Zash type=wait
  95. Sam Whited close.
  96. Zash Maybe that should be one of the remote-server-somethings
  97. Zash This led to a client saying "Room is full" when my Biboumi instance wasn't started
  98. Zash Much fun!
  99. Sam Whited ejabberd also includes "code='503'"… might just pretend I didn't see that, I really hated the stupid HTTP-like error codes.
  100. Zash Pretty sure those are deprecated since decades
  101. Sam Whited yah, if someone complains they can implement it later.
  102. Zash ... Except in MUC!
  103. Sam Whited I assume Cisco or Google or someone still requires them and someone will eventually complain.
  104. Zash Can't remember any complaints about Prosody not sending them
  105. Sam Whited Good to know, thanks
  106. Zash Sam Whited, was your original question about a client(-library)?
  107. Extarv has left
  108. Sam Whited A library, it could be a client or server, just for anything receiving an IQ it doesn't recognize.
  109. Extarv has joined
  110. Zash I think it's best to just return service-unavailable as a generic-catch-all
  111. Sam Whited Yah, I'll do that and type='cancel' so make it clear that they shouldn't retry in this case. Thanks.
  112. Zash In the case of connected clients, it makes it a bit harder to identify connected resources. Tho you can probably tell from timeing anyways.
  113. Sam Whited In this case if you were writing a server with this library that would already be handled for you elsewhere, luckily. Can't remember what I send back for that. This fallback is just for user registered handlers that got routed correctly, but now we don't recognize the IQ payload.
  114. sonny has left
  115. sonny has joined
  116. kikuchiyo has joined
  117. extarv has joined
  118. debacle has joined
  119. extarv has left
  120. lovetox has left
  121. kikuchiyo has left
  122. pulkomandy has left
  123. pulkomandy has joined
  124. Extarv has left
  125. lovetox has joined
  126. pulkomandy has left
  127. pulkomandy has joined
  128. Alex has left
  129. Alex has joined
  130. lovetox has left
  131. lovetox has joined
  132. lovetox has left
  133. lovetox has joined
  134. Sam Whited Trying to figure out a good API for registering handlers for different IQ payloads but I just realized my design was assuming 0 or 1 child elements, which is only true for result="true" IQs. I suppose I could match each separate child element in the IQ to a handler, but I bet if you're including multiple things in an IQ they need the context of all the other child elements too.
  135. Sam Whited And I don't want to decode the entire thing or do any sort of complex query language if I can avoid it; this was supposed to be a bare-bones dead simple way to call events based on elements, fancier stuff can be written by people using the library if they want it, the built in way should just be simple.
  136. Marc has left
  137. Marc has joined
  138. Zash IQ queries must have exactly one child, responses and errors can have 0 to 2 childs
  139. Kev get/set = 1, result = [01], error = [12], from memory.
  140. Sam Whited That's what I had thought, but I couldn't find it in RFC 6120… just did though.
  141. Sam Whited Thanks, *whew* I was scared I'd have to redo all of that.
  142. Sam Whited Not sure what I'll do about errors, but I might just ignore the child element from the get or set
  143. Sam Whited If someone actually wants that payload for some reason they can write their own multiplexer.
  144. Sam Whited or router or whatever this should be called in XMPP land.
  145. lovetox has left
  146. Sam Whited Actually, no, this doesn't have to care about errors since those are already sent in response to something else and those are automatically returned to the user from the function they used to send the original IQ, not handled as incoming IQs.
  147. Sam Whited So that all works out nicely and I just need more coffee I guess.
  148. Kev It's almost always sufficient to route iqs based on name+space of the primary child for get/set, and based on id/from for error/response.
  149. Sam Whited Yah, that was a much better way to say it, thanks. Doing that.
  150. Zash Some basic dispatch based on iq type first maybe
  151. Kev Sorry, yes, I meant type+name+space.
  152. Sam Whited I'm ignoring type actually (except that get/set and error/response are handled in different places as noted)
  153. Kev I wouldn't, FWIW, merge get/set.
  154. Sam Whited yah, I just hand that off to the user; chances are they're going to handle it in the same place with an if statement.
  155. Kev My experience
  156. Kev My experience (with implementations that do that) is that it's unhelpful, but YMMV.
  157. Sam Whited You mean that it's unhelpful to have separate handlers for get/set, or unhelpful to just hand incoming IQs off to the user and let them decide if it's a get or a set?
  158. Kev It's unhelpful to have to start all handlers with if (get)...
  159. Zash In Prosody many of the ones that are split in get and set have a bunch of code overlap, tho it feels safer somehow.
  160. Kev It's not a major wart, but as every handler of which I'm aware needs different behaviour for get and set, it forces every handler anywhere to have the if(get)... scaffolding in it.
  161. Kev And smart money says if you write enough of those, you'll flip the logic for a fun bug some day.
  162. Kev Not that I have any experience of that...
  163. Zash And then one day someone forgets to add that, leading to handling get and set the same way, leading to other things starting to rely on that, leading to a mess.
  164. Kev So I'd gently encourage splitting of get/set handlers for the sake of your consumers, and then go slink back off to the shadows.
  165. pulkomandy has left
  166. Sam Whited Interesting; I'll think about it.
  167. Sam Whited I'd think they'd share so much logic that you'd want the if get/set instead of having a bigger list of handlers to register, but I defer to experience over me just kind of guessing about it
  168. lovetox has joined
  169. Zash Don't think I've seen /that/ much shared logic
  170. Sam Whited Actually, yah, on second thought I bet 90% of handlers are just "if get dbLookup else dbExec"
  171. Sam Whited Maybe it just comes down to whether an if/else or registering two handlers is clearer or requires more boilerplate
  172. Zash I can imagine that some would share some auth checks
  173. Kev I think it both comes down to which is clearer, and which is more likely for someone to slip up.
  174. Kev If you have to register get/set explicitly it's impossible to forget to do so (although you can flip them). If you have to `if` in the call, it's possible to not only flip them, but cause some or all of the code to execute for both when you didn't intend it.
  175. Sam Whited That makes good sense
  176. Zash More explicit to have shared/common code factored out in a function
  177. lovetox has left
  178. lovetox has joined
  179. Wojtek has left
  180. kikuchiyo has joined
  181. kikuchiyo has left
  182. debacle has left
  183. kikuchiyo has joined
  184. kikuchiyo has left
  185. kikuchiyo has joined
  186. kikuchiyo has left
  187. Wojtek has joined
  188. Marc has left
  189. Marc has joined
  190. lovetox has left
  191. serge90 has left
  192. serge90 has joined
  193. Alex has left
  194. Alex has joined
  195. Marc has left
  196. asterix has left
  197. Neustradamus has joined
  198. kikuchiyo has joined
  199. lovetox has joined
  200. kikuchiyo has left
  201. kikuchiyo has joined
  202. lovetox has left
  203. Martin has joined
  204. Wojtek has left
  205. goffi has left
  206. pulkomandy has joined
  207. gav has left
  208. gav has joined
  209. strar has left
  210. strar has joined
  211. Martin has left
  212. kikuchiyo has left
  213. kikuchiyo has joined
  214. debacle has joined
  215. Marc has joined
  216. kikuchiyo has left
  217. Meta Bergman has left
  218. Meta Bergman has joined