XSF Discussion - 2013-05-08

hi Lance!

any further thoughts on our SDP problem?

just that I wish there were easily available SDP parsers

in what languages?

JS and Python

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

I've seen some partial works for that

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

but the SOX idea is looking reasonable

Lance: ugly but practical, yes

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

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

:)

support sox? use that. support jingle? use that

right

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

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

sip/sdp over xmpp

I've completely missed this.

Wherewhowhywhatnow?

it was mentioned at the summit

the main issue is with the direction that webrtc has gone

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

which has standardized on using SDP

I must have not been in that track.

Unless you mean cusax (sp?)

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

Kev: not CUSAX

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

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

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

SoX is for XMPP-only endpoints to send plain SDP

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

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

This sox stuff doesn't sound very appealing!

Kev: yes, very ugly and blobby

but also simpler for certain useful cases

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

and JSON encoding it, for good measure

:)

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

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

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

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

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

yep, with the < in the headers

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

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

:P

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

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

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

speaking of whom! ;-)

Hello!

but multiple implementations are a good thing

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

heehee

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

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

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

Trying to move jdev out of prosody@?

jdev is dead, long live jdev!

Heh

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

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

Rules, pft

that's the spirit!

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

prepping seems like enough

the client could send whole JIDs or only JID-parts

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

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

heh

it's an open question how much really needs to go over XMPP -- many IQ things could happen over HTTP (oh, say, vCard get)

HTTP? You're moving the goalposts :P

Lance, GET or POST?

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

GET should work

cacheable

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

Lance: it's a deal!

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

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

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

\o/

(/prep assumes you named it mod_prep) ✏

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

heh

it is handy

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

yay!

Ha, I just saw your XEP in the backlog

I can make the plugin support that protocol

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

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

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

yeah, makes sense

I'll commit this to prosody-modules

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

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

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

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

Good luck :)

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

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

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

that would work pretty nicely

Makes the code smaller too :)

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

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

except for 418

422 Unprocessable Entity (WebDAV; RFC 4918)

I do like 451 :)

:)

heh

I don't think we ever got that one registered

ok, new version pushed. should match implementation

bah, forgot schema change

Looks perfect

Bah, schemas :)

its ok they're not normative anyway :p

the gods or the schemas? ;-)

haha

:P

ok, now that's updated

do I just email the xml file to you stpeter?

Lance: I can pull it from a URL or whatever

Formalities? This isn't the IETF :)

yeah thankfully :P

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

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

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

who needs a system?

heh

and it's in the inbox

\o/

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

hehe

:)

indeed

make the server do all that work

Long live simple clients

:)

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

yeah, that would be nice

probably just a dream :-)

maybe, but sox is pretty close

really? I don't think so

SoX is just an ugly workaround for offer-answer madness

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

but it's within that same paradigm

hmm, maybe

just grap the sdp blob, send, be happy

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

probably

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

nod

I still worry about silos

but I suppose I always will

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

oh, no, I didn't mean that

its the exact same data in a jingle stanza

yepper

bbl