XSF Discussion - 2013-05-08


  1. stpeter

    hi Lance!

  2. stpeter

    any further thoughts on our SDP problem?

  3. Lance

    just that I wish there were easily available SDP parsers

  4. stpeter

    in what languages?

  5. Lance

    JS and Python

  6. stpeter

    I'm kind of surprised we don't have one in JS given all the WebRTC work happening

  7. Lance

    I've seen some partial works for that

  8. Lance

    I think Phono might have a good implementation, not sure on licensing though

  9. Lance

    but the SOX idea is looking reasonable

  10. stpeter

    Lance: ugly but practical, yes

  11. stpeter

    Lance: I didn't write it up yet, but I think I will before the end of this week

  12. Lance

    right, just one more thing in the disco stack to check

  13. stpeter

    :)

  14. Lance

    support sox? use that. support jingle? use that

  15. stpeter

    right

  16. stpeter

    anyway I will run it up the flagpole and see who salutes :-)

  17. Kev

    Am I being dense that I don't immediately know what sox is?

  18. Lance

    sip/sdp over xmpp

  19. Kev

    I've completely missed this.

  20. Kev

    Wherewhowhywhatnow?

  21. Lance

    it was mentioned at the summit

  22. Lance

    the main issue is with the direction that webrtc has gone

  23. stpeter

    Kev: Lance and I had a chat about it here the other day

  24. Lance

    which has standardized on using SDP

  25. stpeter fishes out the logs

  26. Kev

    I must have not been in that track.

  27. Kev

    Unless you mean cusax (sp?)

  28. stpeter

    http://logs.xmpp.org/xsf/130506/#20:27:18

  29. stpeter

    Kev: not CUSAX

  30. Lance

    so browser apps right now just pass SDP blobs around to set up video/audio sessions

  31. stpeter

    CUSAX is Combined Use of SIP and XMPP = dual-stack clients

  32. Lance

    and browsers dont provide a way to parse or get the raw data in the SDP blob

  33. stpeter

    SoX is for XMPP-only endpoints to send plain SDP

  34. Lance

    so just lots of error prone parsing/translating back and forth to jingle

  35. stpeter

    wow, I haven't logged into stpeter@jabber.org for a while -- I have 100+ buddy requests

  36. Kev

    This sox stuff doesn't sound very appealing!

  37. Lance

    Kev: yes, very ugly and blobby

  38. Lance

    but also simpler for certain useful cases

  39. Kev

    I hope we're putting it inside the message body!

  40. Lance

    and JSON encoding it, for good measure

  41. stpeter

    :)

  42. stpeter

    nice! ".stpeter@jabber.org would like to subscribe to your presence"

  43. 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

  44. Kev

    So you mean I might expect to see things as beautiful as http://xmpp.org/extensions/inbox/zoep.html#examples-call?

  45. Kev

    Because that's what I've always thought has been missing from life.

  46. Kev

    That example's also illegal, isn't it?

  47. Lance

    yep, with the < in the headers

  48. stpeter

    I haven't looked at the ZOEP thing in a long time

  49. Kev

    From what I can tell, you're missing out.

  50. stpeter

    :P

  51. 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

  52. 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

  53. stpeter

    of course, Matthew Wild would say I should do it in Lua ;-)

  54. stpeter

    speaking of whom! ;-)

  55. MattJ

    Hello!

  56. stpeter

    but multiple implementations are a good thing

  57. stpeter

    MattJ: the topic is a server-side service that preps JIDs for you

  58. MattJ bookmarks the room, because one can never have enough bookmarks

  59. stpeter

    heehee

  60. MattJ

    Want one? I can code it in about 5 minutes :)

  61. stpeter

    MattJ: for some reason, Lance and I and a few others seem to use this room for technical discussions at times

  62. stpeter

    MattJ: you can code most everything in 5 minutes :P

  63. MattJ

    Trying to move jdev out of prosody@?

  64. stpeter

    jdev is dead, long live jdev!

  65. MattJ

    Heh

  66. stpeter

    besides, muc.xmpp.org isn't hammered like conference.jabber.org

  67. stpeter

    and I'd assume that XSF IPR rules apply here, for whatever that is worth

  68. MattJ

    Rules, pft

  69. stpeter

    that's the spirit!

  70. MattJ

    Do you also want the server to split it perhaps? or only prepping?

  71. stpeter

    prepping seems like enough

  72. stpeter

    the client could send whole JIDs or only JID-parts

  73. 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

  74. 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

  75. stpeter

    heh

  76. 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)

  77. MattJ

    HTTP? You're moving the goalposts :P

  78. MattJ adds, because it's only another couple of lines...

  79. stpeter glances at PEP-0008

  80. MattJ

    Lance, GET or POST?

  81. Lance

    MattJ: I'd say just prepping the JID as given is enough. Clients can split them pretty easily

  82. Lance

    GET should work

  83. Lance

    cacheable

  84. Lance

    stpeter: If you figure out getting precis to work in Python, i'll bundle it in to sleek

  85. stpeter

    Lance: it's a deal!

  86. 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

  87. MattJ

    Lance, http://q.zash.se/d1302228.txt

  88. MattJ

    GET localhost:5280/prep?jid=USER@HOST

  89. Lance

    \o/

  90. MattJ

    (prep assumes you named it mod_prep)

  91. MattJ

    (/prep assumes you named it mod_prep)

  92. MattJ

    Message correction, I'm growing to like it :)

  93. stpeter

    heh

  94. Lance

    it is handy

  95. 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

  96. stpeter

    yay!

  97. MattJ

    Ha, I just saw your XEP in the backlog

  98. MattJ

    I can make the plugin support that protocol

  99. Lance

    Yeah, it's pretty much identical already, just a namespace change

  100. Lance

    But specifying jid-malformed for the error response is a good idea

  101. MattJ

    I chose not to nest the <jid>, just makes the code simpler, and I didn't see a need for it

  102. Lance

    yeah, makes sense

  103. MattJ

    I'll commit this to prosody-modules

  104. Lance

    i think i was modelling how bind works, but that's not needed if we're not splitting

  105. MattJ

    along with a couple of other plugins I've been working on...

  106. stpeter

    sheesh, my inbox is back at 666 messages -- why don't I seem able to shake that?

  107. stpeter

    I'll need to delete a whole lot of messages, I think ;-)

  108. MattJ

    Good luck :)

  109. stpeter

    I got it down from ~3000 to this number and just got stuck

  110. MattJ

    Lance, I'll change the namespace to urn:xmpp:jidprep:tmp

  111. MattJ

    and wondering if perhaps the JID could just go in the path... GET /prep/user@host

  112. Lance

    that would work pretty nicely

  113. MattJ

    Makes the code smaller too :)

  114. MattJ

    and it now returns HTTP 400 on an invalid JID, unless you have a better code

  115. Lance

    i can't think of one off the top of my head

  116. Lance

    except for 418

  117. MattJ

    422 Unprocessable Entity (WebDAV; RFC 4918)

  118. MattJ

    I do like 451 :)

  119. Lance

    :)

  120. stpeter

    heh

  121. stpeter

    I don't think we ever got that one registered

  122. MattJ is a Bradbury fan

  123. Lance

    ok, new version pushed. should match implementation

  124. Lance

    bah, forgot schema change

  125. MattJ

    Looks perfect

  126. MattJ

    Bah, schemas :)

  127. stpeter shakes his fist at the XML gods!

  128. Lance

    its ok they're not normative anyway :p

  129. stpeter

    the gods or the schemas? ;-)

  130. Lance

    haha

  131. MattJ

    :P

  132. Lance

    ok, now that's updated

  133. Lance

    do I just email the xml file to you stpeter?

  134. stpeter

    Lance: I can pull it from a URL or whatever

  135. stpeter finds http://legastero.github.io/customxeps/extensions/jidprep.xml

  136. MattJ

    Formalities? This isn't the IETF :)

  137. stpeter

    yeah thankfully :P

  138. stpeter

    I'm going to experiment with literate programming in my i18n program, we'll see how it goes :-)

  139. Lance

    the only problem I ever had with literate programming was that none of the systems worked like I wanted it to

  140. Lance

    i think its a rite of passage, making your own literate programming framework

  141. stpeter

    who needs a system?

  142. stpeter

    heh

  143. stpeter

    and it's in the inbox

  144. Lance

    \o/

  145. Lance

    and now I don't have to feel bad about not bundling Mbs of character data to stringprep in the browser

  146. stpeter

    hehe

  147. MattJ

    :)

  148. stpeter

    indeed

  149. stpeter

    make the server do all that work

  150. MattJ

    Long live simple clients

  151. stpeter

    :)

  152. 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...

  153. Lance

    yeah, that would be nice

  154. stpeter

    probably just a dream :-)

  155. Lance

    maybe, but sox is pretty close

  156. stpeter

    really? I don't think so

  157. stpeter

    SoX is just an ugly workaround for offer-answer madness

  158. Lance

    especially since most clients just use a web view anyway which will eventually have webrtc support

  159. stpeter

    but it's within that same paradigm

  160. stpeter

    hmm, maybe

  161. Lance

    just grap the sdp blob, send, be happy

  162. stpeter

    you're more of an optimist than I am :P

  163. Lance

    probably

  164. Lance

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

  165. stpeter

    nod

  166. stpeter

    I still worry about silos

  167. stpeter

    but I suppose I always will

  168. Lance

    i dont think sox would be any more siloable than things already are

  169. stpeter

    oh, no, I didn't mean that

  170. Lance

    its the exact same data in a jingle stanza

  171. stpeter

    yepper

  172. stpeter

    bbl