jdev - 2020-02-13

  1. kikuchiyo has joined

  2. kikuchiyo has left

  3. kikuchiyo has joined

  4. pulkomandy has left

  5. pulkomandy has joined

  6. Zash has left

  7. kikuchiyo has left

  8. moparisthebest has left

  9. debacle has left

  10. moparisthebest has joined

  11. kikuchiyo has joined

  12. kikuchiyo has left

  13. kikuchiyo has joined

  14. kikuchiyo has left

  15. kikuchiyo has joined

  16. larma has left

  17. kikuchiyo has left

  18. kikuchiyo has joined

  19. kikuchiyo has left

  20. Sam Whited has left

  21. larma has joined

  22. Sam Whited has joined

  23. kikuchiyo has joined

  24. kikuchiyo has left

  25. goffi has joined

  26. goffi has left

  27. goffi has joined

  28. goffi has left

  29. goffi has joined

  30. goffi has left

  31. goffi has joined

  32. kikuchiyo has joined

  33. Martin has joined

  34. kikuchiyo has left

  35. kikuchiyo has joined

  36. asterix has joined

  37. kikuchiyo has left

  38. pulkomandy has left

  39. pulkomandy has joined

  40. pulkomandy has left

  41. pulkomandy has joined

  42. debacle has joined

  43. kikuchiyo has joined

  44. Zash has joined

  45. kikuchiyo has left

  46. asterix has left

  47. asterix has joined

  48. pulkomandy has left

  49. pulkomandy has joined

  50. kikuchiyo has joined

  51. Marc has left

  52. kikuchiyo has left

  53. pulkomandy has left

  54. Marc has joined

  55. kikuchiyo has joined

  56. pulkomandy has joined

  57. pulkomandy has left

  58. pulkomandy has joined

  59. debacle has left

  60. pulkomandy has left

  61. pulkomandy has joined

  62. Marc has left

  63. Marc has joined

  64. pulkomandy has left

  65. pulkomandy has joined

  66. pulkomandy has left

  67. debacle has joined

  68. sonny has left

  69. sonny has joined

  70. paul has left

  71. paul has joined

  72. Alex has left

  73. strar has left

  74. Martin has left

  75. Martin has joined

  76. Alex has joined

  77. Marc has left

  78. Marc has joined

  79. Alex has left

  80. Alex has joined

  81. strar has joined

  82. strar has left

  83. strar has joined

  84. strar has left

  85. strar has joined

  86. serge90 has left

  87. serge90 has joined

  88. pulkomandy has joined

  89. asterix has left

  90. asterix has joined

  91. pulkomandy has left

  92. pulkomandy has joined

  93. pulkomandy has left

  94. pulkomandy has joined

  95. arashi has left

  96. arashi has joined

  97. pulkomandy has left

  98. pulkomandy has joined

  99. Wojtek has joined

  100. aj has joined

  101. aj has left

  102. Sam Whited

    Pushed out a description of the changes I was asking about yesterday, in case anyone is curious or has feedback: https://github.com/mellium/xmpp/blob/master/design/0002_iqmux.md

  103. Sam Whited

    WIP, but the important bits are laid out.

  104. Marc has left

  105. Marc has joined

  106. flow

    Sam Whited, does the API allow to register IQMux's that are not an IQ?

  107. flow

    "func HandleIQ(iqType stanza.IQType, n xml.Name, h IQHandler)" does not look that way?

  108. flow

    actually I am not sure if this is the function to register a handler or not

  109. Sam Whited

    flow: yah, sorry, without more context this is likely confusing. The xmpp package has a HandleXMPP function used to register a single handler for all stanzas. You can choose to use this mux package (or write your own) to register a mux as that handler. The mux can have its own handlers.

  110. flow

    hmm, no, does not look that way

  111. Sam Whited

    Similarly, the IQHandler has to be registered on the mux for *all* IQs, and then it has its own handlers for IQs.

  112. Sam Whited

    So the question would be what happens if the IQMux is registered as the handler for eg. messages instead of IQs?

  113. flow

    Sam Whited, FWIW Smack registers IQ request handlers by QName and iq-request type (get|set), nothing more. IQ request handlers are an first-class concept besides (what one could call) generic stanza handlers in Smack. Those are not able to handle IQ requests, which was a deliberate design choice so that smack is able to reply with an error if no IQ request handler is registered for a given IQ

  114. flow

    Sam Whited, FWIW Smack registers IQ request handlers by QName and iq-request type (get|set), nothing more. IQ request handlers are an first-class citizen besides (what one could call) generic stanza handlers in Smack. Those are not able to handle IQ requests, which was a deliberate design choice so that smack is able to reply with an error if no IQ request handler is registered for a given IQ

  115. pulkomandy has left

  116. pulkomandy has joined

  117. Sam Whited

    Yah, we don't have a concept of handlers for different things built in by default because the main library is supposed to be pretty low level. You just get a single handler that all top level stream elements (that aren't stream:stream elements) get passed to.

  118. Sam Whited

    It also means the routing can be swapped out; if you don't like this simple router, you can create your own (it just has to implement the handler interface) that does whatever that XML query language is or whatever you prefer

  119. flow

    Sam Whited, I assume this is not meant as pure xmpp client library? Guess things are different then

  120. flow

    Then I guess it is by design that the API appears to allow you to install a handler for 'error' type IQs

  121. Sam Whited

    That's a question I have too at the bottom; right now if you send an IQ (this is all part of a separate API) and you get an IQ result or error, that gets automatically passed back to the function you sent the IQ from so that the user can do something with it (see https://pkg.go.dev/mellium.im/xmpp#Session.SendIQ). However, if that has timed out and the function has returned, should it be passed to this handler for the user to handle or ignore? Eg. they may want to log it as a timeout or unhandled response.

  122. Sam Whited

    I think the answer is "yes", because even if it's timed out I don't think anything should ever be sent over the stream that's automatically ignored, the user should have the option of doing something with it. But I'm not 100% sure.

  123. Sam Whited

    And it is meant as a pure XMPP client library, if you mean "does it follow the spec?", but parts of it are pretty modular. If the users swap out the standard compliant parts to support some weird Cisco or Google brokenness, that's fine.

  124. Sam Whited

    (but they'll have to do that, I don't develop them as part of the main project)

  125. Sam Whited

    When we handle an incomming IQ too (regardless of whether a handler exists or not), we monitor what's being written back to the stream from the handler. If no error or result is written, when the handler returns the library automatically responds to the IQ with some generic result or error, I forget what.

  126. Sam Whited

    Sorry for the wall of text to answer both questions.

  127. pulkomandy has left

  128. pulkomandy has joined

  129. flow

    I never had the desire to handle timed-out IQ responses (but smack would allow for that)

  130. flow

    (or actually, on this layer it is currently undecidable in smack if someone is still waiting for the IQ response or not)

  131. flow

    Don't get me wrong, it sure could be helpful to have that as diagnostic feature (e.g., "your timeout is to low"), it just isn't a high priority to implement for me

  132. Sam Whited

    Yah, probably not the end of the world. Although, I think I convinced myself just now that the behavior should be that this can handle Error and Result types (with a note about how you'll only receive them if a timeout happened or the user specifically sent them with one of the raw token encoding APIs instead of SendIQ or SendIQElement which are the two things that actually handle responses)

  133. Sam Whited

    So I may add two more options for that.

  134. Sam Whited

    I also wonder if there's a more general way to handle this; eg. does it make sense to have a handler for messages and presence? I don't think so since I don't know what it would even match on, but I'm not sure

  135. Sam Whited

    Without having to decode the entire stanza up front, that is.

  136. flow

    I think one could do the decoding lazily

  137. Sam Whited

    Actually, I was forgetting that error IQs will have this same problem. I always decode lazily, but if the error isn't the first child element, I don't want to match on the original payload and execute a handler for it.

  138. flow

    but besides that, you have to parse the input xml anyway to determine the stanza boundaries, might as well decode it (at least a little bit). I think what smack does could be described as decoding the stanza always

  139. Sam Whited

    This library deliberately doesn't do that; it operates on XML tokens instead of entire elements (then gives you the option to decode the tokens into a struct or map or however you do things in your handlers)

  140. pulkomandy has left

  141. flow

    tbh, I don't see the advantage

  142. Sam Whited

    Actually, this is fine, I'll just special case error and instead of matching on the child payload that always matches the whole IQ. I think that will be okay. It's a bit weird, I hate special cases, but error is a special case in the protocol so it makes sense that it would have to be in the library too.

  143. Sam Whited

    No, I don't even have to special case it. This is up to the user, I'll just document it. If you're registering a handler for errors, better make it a wildcard on the XML name. Easy.

  144. pulkomandy has joined

  145. Sam Whited

    flow: the benefit in this case (which admittedly is niche and most people don't need it, but this is a lower level library meant to make an XMPP client library on top of) is constant memory use (more or less).

  146. Kev

    Sam Whited: At least at the library level. Pretty much every application is going to need to do a full decode in the end.

  147. Kev

    (Or I misunderstood the point)

  148. Sam Whited

    Kev: yup, and now it's up to the user writing an XMPP client library with this backing it how to do that. They may have their own schemas for specific types, they may have a generic XML representation, etc.

  149. flow

    Sam Whited, so entities inspecting a stanza only have a linear stream of xml events available?

  150. asterix has left

  151. flow

    is it really constant memory use or *minimal* memory use?

  152. Sam Whited

    flow: yes, when you register a handler every time a new top level stream element is encountered it is given the start element that triggered the call (eg. a new <message>) and a thing that can be used to pop more tokens from the stream (but is limited to the element the handler is called on, it won't give you anymore if you try to advance beyond </message>). When the handler returns, the library advances to the end of that element (if there are any tokens left to pop) and then continues.

  153. pulkomandy has left

  154. Sam Whited

    flow: it's not exactly constant, but we're generating less garbage than if we were converting those tokens into a struct or whatever. It is pretty minimal (or would be if the Go xml library weren't terrible, but that can be swapped out later)

  155. asterix has joined

  156. Sam Whited

    And it lets the user convert those into whatever representation they want.

  157. flow

    cause I'd say once Smack has consumed an xml stanza the resulting java object instance also has constant memory use ;)

  158. Sam Whited

    The hypothesis is that tokens are all going to be around the same size (excluding character data payloads sometimes, eg. messages or IBB data, etc.). But if you were decoding things you'd have to both have those tokens *and* decode them into a struct or whatever your data type is.

  159. Sam Whited

    That's the hypothesis anyways: tokens are probably all roughly similar size and you can throw them away quicker instead of having to buffer all of them and do parsing and create more objects. That's up to the user to decide how they do that in this case.

  160. Sam Whited

    oops, somehow I thought that errored the first time, sorry for the rephrase of the same thing.

  161. pulkomandy has joined

  162. Sam Whited

    But the memory use is really less interesting than just being low level and letting the user decode data however they want I think.

  163. Zash has left

  164. Zash has joined

  165. Sam Whited

    After experimenting with it, I'm very happy to just have a shortcut to register a handler for all Error type IQs that ignores the payload. Doesn't feel special cased, makes it easy to log errors that weren't handled for one reason or another or do manual error handling if you don't like the way the library waits for an error response

  166. asterix has left

  167. Sam Whited

    Pushed an update with the new API and updated comments to explain it

  168. Sam Whited

    Thanks for all the feedback, just talking through it out loud has been really helpful too.

  169. pulkomandy has left

  170. pulkomandy has joined

  171. pulkomandy has left

  172. pulkomandy has joined

  173. pulkomandy has left

  174. pulkomandy has joined

  175. pulkomandy has left

  176. kikuchiyo has left

  177. debacle has left

  178. Martin has left

  179. Martin has joined

  180. lovetox has joined

  181. asterix has joined

  182. Martin has left

  183. kikuchiyo has joined

  184. Martin has joined

  185. Marc has left

  186. Marc has joined

  187. Martin has left

  188. Martin has joined

  189. kikuchiyo has left

  190. debacle has joined

  191. flow

    Always happy to act as rubber duck ;)

  192. Zash

    Hmm, rubber ducks as swag for FOSDEM and such?

  193. Zash

    🦆️<(use XMPP)

  194. paul has left

  195. kikuchiyo has joined

  196. kikuchiyo has left

  197. paul has joined

  198. Martin has left

  199. Martin has joined

  200. Martin has left

  201. Martin has joined

  202. Marc has left

  203. Marc has joined

  204. Martin has left

  205. kikuchiyo has joined

  206. asterix has left

  207. paul has left

  208. Martin has joined

  209. paul has joined

  210. paul has left

  211. paul has joined

  212. Alex has left

  213. pulkomandy has joined

  214. goffi has left

  215. moparisthebest has left

  216. debacle has left

  217. debacle has joined

  218. debacle has left

  219. Alex has joined

  220. lovetox has left

  221. pulkomandy has left

  222. sonny has left

  223. pulkomandy has joined

  224. pulkomandy has left

  225. pulkomandy has joined

  226. sonny has joined

  227. debacle has joined