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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  169. MattJ


  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


  181. stpeter

    and it's in the inbox

  182. Lance


  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


  185. MattJ


  186. stpeter


  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


  202. Lance

    but its looking like webrtc will hopefully solve a lot of these problems and pave the road

  203. stpeter


  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


  210. stpeter


  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