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


  95. Sam Whited


  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