XSF Discussion - 2013-05-08

  1. Lance has joined
  2. Lance has joined
  3. stpeter has left
  4. Jef has left
  5. kevin has joined
  6. Lance has joined
  7. Lance has joined
  8. jabberjocke has left
  9. Lance has left
  10. jabberjocke has joined
  11. Alex has joined
  12. Alex has left
  13. jabberjocke has left
  14. Alex has joined
  15. Neustradamus has joined
  16. Lloyd has joined
  17. kevin has left
  18. kevin has joined
  19. jabberjocke has joined
  20. jabberjocke has left
  21. kevin has left
  22. kevin has joined
  23. stpeter has joined
  24. Alex has left
  25. Florob has joined
  26. jabberjocke has joined
  27. Florob has left
  28. Lance has joined
  29. stpeter hi Lance!
  30. stpeter any further thoughts on our SDP problem?
  31. Lance just that I wish there were easily available SDP parsers
  32. stpeter in what languages?
  33. Lance JS and Python
  34. stpeter I'm kind of surprised we don't have one in JS given all the WebRTC work happening
  35. Lance I've seen some partial works for that
  36. Lance I think Phono might have a good implementation, not sure on licensing though
  37. Lance but the SOX idea is looking reasonable
  38. stpeter Lance: ugly but practical, yes
  39. stpeter Lance: I didn't write it up yet, but I think I will before the end of this week
  40. Lance right, just one more thing in the disco stack to check
  41. stpeter :)
  42. Lance support sox? use that. support jingle? use that
  43. stpeter right
  44. stpeter anyway I will run it up the flagpole and see who salutes :-)
  45. Kev Am I being dense that I don't immediately know what sox is?
  46. Lance sip/sdp over xmpp
  47. Kev I've completely missed this.
  48. Kev Wherewhowhywhatnow?
  49. Lance it was mentioned at the summit
  50. Lance the main issue is with the direction that webrtc has gone
  51. stpeter Kev: Lance and I had a chat about it here the other day
  52. Lance which has standardized on using SDP
  53. stpeter fishes out the logs
  54. Kev I must have not been in that track.
  55. Kev Unless you mean cusax (sp?)
  56. stpeter http://logs.xmpp.org/xsf/130506/#20:27:18
  57. stpeter Kev: not CUSAX
  58. Lance so browser apps right now just pass SDP blobs around to set up video/audio sessions
  59. stpeter CUSAX is Combined Use of SIP and XMPP = dual-stack clients
  60. Lance and browsers dont provide a way to parse or get the raw data in the SDP blob
  61. stpeter SoX is for XMPP-only endpoints to send plain SDP
  62. Lance so just lots of error prone parsing/translating back and forth to jingle
  63. stpeter wow, I haven't logged into stpeter@jabber.org for a while -- I have 100+ buddy requests
  64. Kev This sox stuff doesn't sound very appealing!
  65. Lance Kev: yes, very ugly and blobby
  66. Lance but also simpler for certain useful cases
  67. Kev I hope we're putting it inside the message body!
  68. Lance and JSON encoding it, for good measure
  69. stpeter :)
  70. stpeter nice! ".stpeter@jabber.org would like to subscribe to your presence"
  71. stpeter Kev: in fact, SoX is just about the ugliest thing you've ever seen, but it works -- it's really http://xmpp.org/extensions/inbox/zoep.html revisited
  72. Kev So you mean I might expect to see things as beautiful as http://xmpp.org/extensions/inbox/zoep.html#examples-call?
  73. Kev Because that's what I've always thought has been missing from life.
  74. Kev That example's also illegal, isn't it?
  75. Lance yep, with the < in the headers
  76. stpeter I haven't looked at the ZOEP thing in a long time
  77. Kev From what I can tell, you're missing out.
  78. stpeter :P
  79. Lloyd has left
  80. Alex has joined
  81. Lance has joined
  82. kevin has left
  83. kevin has joined
  84. Lance has joined
  85. Lance has left
  86. Lance has joined
  87. Lance stpeter: I also started on a xep for letting a server prep jids a client sends it: http://legastero.github.io/customxeps/extensions/jidprep.html
  88. stpeter Lance: ah, good, I've been thinking a lot in the last 24 hours about some Python code for internationalization, but only to output the codepoint tables for IDNA2008 and PRECIS
  89. stpeter of course, Matthew Wild would say I should do it in Lua ;-)
  90. MattJ has joined
  91. stpeter speaking of whom! ;-)
  92. MattJ Hello!
  93. stpeter but multiple implementations are a good thing
  94. stpeter MattJ: the topic is a server-side service that preps JIDs for you
  95. MattJ bookmarks the room, because one can never have enough bookmarks
  96. stpeter heehee
  97. MattJ Want one? I can code it in about 5 minutes :)
  98. stpeter MattJ: for some reason, Lance and I and a few others seem to use this room for technical discussions at times
  99. stpeter MattJ: you can code most everything in 5 minutes :P
  100. MattJ Trying to move jdev out of prosody@?
  101. stpeter jdev is dead, long live jdev!
  102. MattJ Heh
  103. stpeter besides, muc.xmpp.org isn't hammered like conference.jabber.org
  104. stpeter and I'd assume that XSF IPR rules apply here, for whatever that is worth
  105. MattJ Rules, pft
  106. stpeter that's the spirit!
  107. MattJ Do you also want the server to split it perhaps? or only prepping?
  108. stpeter prepping seems like enough
  109. stpeter the client could send whole JIDs or only JID-parts
  110. stpeter as Jack pointed out in the related email thread a while back, that doesn't help you until you're connected to the XMPP server, so one might want to offer an HTTP service as well, but IMHO the XMPP service would be a fine start
  111. Lance yeah, an HTTP service would be nice, but at that point, a whole heck of a lot of XMPP data would be nice to have exposed over standardized REST calls
  112. stpeter heh
  113. stpeter it's an open question how much really needs to go over XMPP -- many IQ things could happen over HTTP (oh, say, vCard get)
  114. MattJ HTTP? You're moving the goalposts :P
  115. MattJ adds, because it's only another couple of lines...
  116. stpeter glances at PEP-0008
  117. MattJ Lance, GET or POST?
  118. Lance MattJ: I'd say just prepping the JID as given is enough. Clients can split them pretty easily
  119. Lance GET should work
  120. Lance cacheable
  121. Lance stpeter: If you figure out getting precis to work in Python, i'll bundle it in to sleek
  122. stpeter Lance: it's a deal!
  123. stpeter Lance: but step one is to at least figure out how to output the tables I need -- that might lead to a building block we can use
  124. MattJ Lance, http://q.zash.se/d1302228.txt
  125. MattJ GET localhost:5280/prep?jid=USER@HOST
  126. Lance \o/
  127. MattJ (prep assumes you named it mod_prep)
  128. MattJ (/prep assumes you named it mod_prep)
  129. MattJ Message correction, I'm growing to like it :)
  130. stpeter heh
  131. Lance it is handy
  132. Lance ok, so prosody supports this now, and that's all that counts. so time to tidy up this protoxep and send it to the editor
  133. stpeter yay!
  134. MattJ Ha, I just saw your XEP in the backlog
  135. MattJ I can make the plugin support that protocol
  136. Lance Yeah, it's pretty much identical already, just a namespace change
  137. Lance But specifying jid-malformed for the error response is a good idea
  138. MattJ I chose not to nest the <jid>, just makes the code simpler, and I didn't see a need for it
  139. Lance yeah, makes sense
  140. MattJ I'll commit this to prosody-modules
  141. Lance i think i was modelling how bind works, but that's not needed if we're not splitting
  142. MattJ along with a couple of other plugins I've been working on...
  143. stpeter sheesh, my inbox is back at 666 messages -- why don't I seem able to shake that?
  144. stpeter I'll need to delete a whole lot of messages, I think ;-)
  145. MattJ Good luck :)
  146. stpeter I got it down from ~3000 to this number and just got stuck
  147. Jef has joined
  148. MattJ Lance, I'll change the namespace to urn:xmpp:jidprep:tmp
  149. MattJ and wondering if perhaps the JID could just go in the path... GET /prep/user@host
  150. Lance that would work pretty nicely
  151. MattJ Makes the code smaller too :)
  152. MattJ and it now returns HTTP 400 on an invalid JID, unless you have a better code
  153. Lance i can't think of one off the top of my head
  154. Lance except for 418
  155. MattJ 422 Unprocessable Entity (WebDAV; RFC 4918)
  156. MattJ I do like 451 :)
  157. Lance :)
  158. stpeter heh
  159. stpeter I don't think we ever got that one registered
  160. MattJ is a Bradbury fan
  161. Lance ok, new version pushed. should match implementation
  162. Lance bah, forgot schema change
  163. MattJ Looks perfect
  164. MattJ Bah, schemas :)
  165. stpeter shakes his fist at the XML gods!
  166. Lance its ok they're not normative anyway :p
  167. stpeter the gods or the schemas? ;-)
  168. Lance haha
  169. MattJ :P
  170. Lance ok, now that's updated
  171. Lance do I just email the xml file to you stpeter?
  172. stpeter Lance: I can pull it from a URL or whatever
  173. stpeter finds http://legastero.github.io/customxeps/extensions/jidprep.xml
  174. MattJ Formalities? This isn't the IETF :)
  175. stpeter yeah thankfully :P
  176. stpeter I'm going to experiment with literate programming in my i18n program, we'll see how it goes :-)
  177. Lance the only problem I ever had with literate programming was that none of the systems worked like I wanted it to
  178. Lance i think its a rite of passage, making your own literate programming framework
  179. stpeter who needs a system?
  180. stpeter heh
  181. stpeter and it's in the inbox
  182. Lance \o/
  183. Lance and now I don't have to feel bad about not bundling Mbs of character data to stringprep in the browser
  184. stpeter hehe
  185. MattJ :)
  186. stpeter indeed
  187. stpeter make the server do all that work
  188. MattJ Long live simple clients
  189. stpeter :)
  190. stpeter that brings me back to Jingle and SDP and SoX -- what I had always hoped for was a way for the client to tell the server "hey I want to call Alice" and the server would work out all the details -- the whole offer/answer model is so complex...
  191. Lance yeah, that would be nice
  192. stpeter probably just a dream :-)
  193. Lance maybe, but sox is pretty close
  194. stpeter really? I don't think so
  195. stpeter SoX is just an ugly workaround for offer-answer madness
  196. Lance especially since most clients just use a web view anyway which will eventually have webrtc support
  197. stpeter but it's within that same paradigm
  198. stpeter hmm, maybe
  199. Lance just grap the sdp blob, send, be happy
  200. stpeter you're more of an optimist than I am :P
  201. Lance probably
  202. Lance but its looking like webrtc will hopefully solve a lot of these problems and pave the road
  203. stpeter nod
  204. stpeter I still worry about silos
  205. stpeter but I suppose I always will
  206. Lance i dont think sox would be any more siloable than things already are
  207. stpeter oh, no, I didn't mean that
  208. Lance its the exact same data in a jingle stanza
  209. stpeter yepper
  210. stpeter bbl
  211. stpeter has left
  212. kevin has left
  213. kevin has joined
  214. Alex has left
  215. jabberjocke has left
  216. Neustradamus has left
  217. Neustradamus has joined
  218. Lance has left
  219. Lance has joined
  220. Lance has left
  221. Lance has joined