Strophe.js needs a roadmap for websockets

[plievone]

There is an existing websocket version of strophe.js (see https://github.com/superfeedr/strophejs/tree/protocol-ed/src, https://github.com/superfeedr/msgboy/tree/master/lib/strophejs and http://code.google.com/p/node-xmpp-bosh/) and the author of strophe.js has recently drafted xmpp-over-websockets (http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-00).

Still, there is no mention of websockets at all on strophe.js project. Elaborating on your plans for websockets would increase the perceived viability of this project.

[astro]

I am just helping to push development forward due to metajack's lack of time. Websocket support is highly interesting, but I regard it as just a further optimization over already-working BOSH. Please open pull requests.

The superfeedr branch does not implement the IETF draft. Instead it uses Socket.IO which adds a few bits to Websocket messages. Socket.IO is not really needed; instead of the built-in fallback BOSH would probably a better fit in the absence of Websockets.

While highly-compatible abstractions like Socket.IO and SockJS are lovely, an implementation on top an existing (draft) spec is more favourable. It'd be nice if you could respect that when preparing a patchset.

Also, please make sure both transport implementations stay usable (ie. BOSH + Websocket). The superfeedr branch does that from what I glimpsed.

[flosse]

Are there any known implementations based on the IETF-Draft? And what does Expires: June 11, 2011 in the spec mean?

[loopingrage]

@astro Are you still interested in pull requests that implement draft-moffitt-xmpp-over-websocket-00? If so, I may find some time to work on it this week.

[flosse]

@loopingrage I'd love to see some progress in that topic!

[loopingrage]

I wonder if anyone has built an XMPP/WebSockets connection manager like the ones that exist for BOSH. I know ejabberd has WS support but seems like a standalone connection manager may come in handy as well. I can look into that as well while I'm at it.

[plievone]

@loopingrage https://github.com/dhruvbird/node-xmpp-bosh has a websocket server too.

[flosse]

@loopingrage did you already implemented something?
Here is another interesting project that might be interesting: https://github.com/eldonilo/lightstring

[lboynton]

Looking through the history of the superfeedr branch, it was originally using websockets without Socket.IO. Look at: https://github.com/superfeedr/strophejs/commit/94a36ffa4098777980e4accab13ad5f507487148#src

Perhaps a clean branch could be made using the work from the superfeedr branch up until Socket.IO was added?

[astro]

For the record, I've started implementing BOSH & Websockets in node-xmpp. Using browserify an application can be bundled with all libraries and both connection flavours already work in the browser! I'm testing with node-xmpp-bosh for the server side.

End of shameless self-plug; the node-xmpp experiments are not release-ready so far.

[lboynton]

@astro Can your implementation be used with strophe? I guess it replaces the BOSH handling in strophe?

I'm thinking about when websockets should be used. Should it automatically detect if the browser can support it and use it? Or should it always use BOSH unless configured to use websockets?

[astro]

@lboynton No, node-xmpp is an XMPP library of its own, mostly adhering to node.js conventions. A drop-in Strophe.js replacement on top of my code might be useful but it's not a sexy hack.

Yes, ideally BOSH should be a fallback to missing Websockets support.

[mweibel]

Please take a look at my implementation of a protocolified strophe.js:
https://github.com/mweibel/strophejs/tree/protocolified

It works so far but I think it could need some love :)
Basicly I got my inspiration from superfeedrs protocol-ed branch but built upon the latest strophe.js code.

[Gordin]

Hi,I also created a fork that supports Websockets based on the latest master here:
https://github.com/Gordin/strophejs

I think this is the only fork so far that is not based on superfeedrs branch (I did use some functions from websocket.js though). Unlike branches based on superfeedr this branch is API-compatible (except that attach doesn't work with WebSockets) and detects automatically which protocol should be used by looking at the given url. I tried to reuse as much code as possible so basically the structure of Strophe didn't change and most Strophe-functions now have functions of the same name that protocol objects have to implement. I tried to split my changes in enough commits to make clear what I changed exactly.

If possible, I would like to have this merged upstream and send a pull request.
Any Comments? :)

[mweibel]

I just glanced over it (didn't test it) and it seems pretty cool, although I'd like it more if those additional protocols would've been in an own file - this would make it easier to add other protocols like socket io etc.

[Gordin]

Yes, the protocols should have their own file, but splitting this up is easy, I kept them in one file for now because diffing code that was split up from multiple files is a pain. I will split this up if it's "finished"

[mweibel]

@Gordin I just tried your branch and ran into this error:
this._buildBody is not a function
var body = this._buildBody();

Happens on line 2460

//Edit:
There's also the first stanza which can't be parsed correctly (Because it's not a valid xml):

RECV: <body xmlns='http://jabber.org/protocol/httpbind'>
<parsererror>
XML Parsing Error: no element found Location: http://localhost:8000/user/ Line Number 1, Column 146:
<sourcetext>
<stream:stream version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='900132851' from='localhost'>
 -------------------------------------------------------------------------------------------------------------------------------------------------^
</sourcetext>
</parsererror>
</body>

[Gordin]

@mweibel Could you open an issue for this on my branch? (I don't want to spam this issue here)
Also, on what XMPP Server did you test this? I'd like to reproduce this.

[mweibel]

Sure, sorry ;)

@Gordin: You'd need to enable Issues for that on your fork :)

[Gordin]

The bug @mweibel found has it's own issue here now and I think I fixed it.
I'd be happy if people could verify this. (the bug appeared while trying to connect through websockets with ejabberd and mod_websocket)
So far I tested it against node-xmpp-bosh, WXG, prosody with latest checkout of prosody-modules and ejabberd with latest checkout of mod_websocket (this one, experimental-websocket-final branch).
I'd appreciate further testing though...

[nmaster]

@Gordin: please make sure you take into account the changes included in the latest version of XMPP over WebSockets, if not done already. Here is a diff.

[Gordin]

@nmaster the only "big" changes seem to be that stream start and end tags now must be sent in their own messages (Which was the only case all existing websocket branches supported anyway, I think) and that in case of a stream error during stream setup the complete stream including the error has to be sent together in one message. My branch can handles this now. (I guess, I don't now if any server actually sends the error like this)
While implementing this I noticed that my branch didn't handle stream:error tags at all. It now does...

[nmaster]

@Gordin: sounds good.

[mweibel]

Btw. I'm using my own branch (not @Gordin's) to test websockets and it will be go into production in some weeks.
Looks good so far.

I'm not using Gordin's branch because being API compatible isn't actually my goal. When not being API compatible, implementors of the library can freely choose per connection what type of connection should be made (i.e. you could implement a fallback mechanism which automatically choses BOSH when Websockets fail after some attempts).
Also it seems that the websocket implementation I'm currently using will fail when doing a stream:start with an ending /> instead of leaving it open (which is the desired behaviour according to the spec).

[Gordin]

@mweibel Why would you need to not be API compatible to choose between Websockets and BOSH? You can choose this freely per connection in my branch as well. When you open a Connection with a ws:// URL it uses Websockets and otherwise falls back to BOSH. Choosing this by giving the Connection another Objects doesn't add any information or flexibility, as what Protocol you want to use depends on the URL you connect to anyway. I also don't see why having a fallback mechanism would be any harder to implement in my branch.
You're right about the /> though. I kept this in because at least one of the servers/proxies I tested with sent the stream:start this way and I wanted to test with it anyway. I'll make it conform to the spec though, will be a one-liner. (maybe another line for a proper error message...)

Also, my branch is used in ROLE (Responsive Open Learning Environments) since the last release and seems really stable. Actually I'm currently just commenting code and cleaning it up a bit and will try a pull request here when that's done.

[Letterus]

Hello everyone,

I don't know if you already recognized that ProcessOne has published its implementation of Websockets using Strophe a few days ago: https://gist.github.com/processone/739147

What do you think about it?

[pavelsmolka]

Correct me if I'm wrong, but there is no fallback to BOSH in ProcessOne's library, is there?

[Gordin]

@Letterus I did not get around to test this yet but I've read over it. Things I noticed:
To answer @pavelsmolka s question: throw "no websocket support"
They don't use Strophe to create all their stanzas but construct their stanzas by hand in a few places.
Not all stanzas that are sent will go through the xmloutput or xmlinput functions during stream setup.
I had a few issues with some servers sending the opening stream tag selfclosing or that needed me to send it selfclosing, so I implemented a little workaround for that. I don't see anything like that in their code so I bet this will not work with all servers that are currently capable of XMPP over Websocket. Again, didn't test this though. (Failing in the cases I mentioned is XEP compliant though to be fair.)
They use correct namespaces...:

// Because FF wants valid XML, with correct namespaces !
return this._parser.parseFromString("<body xmlns:stream='foo' >" + elem + "</body>", "text/xml")

Other than that it looks like they made changes similar to what I did on my branch.
I'll still suggest to merge my branch instead of their version though :P

[michfield]

I also suggest to merge @Gordin branch as API compatibility is big deal for me.
API compatibility is a big deal for any casual Strophe user, learning by examples scattered all over the net.

[graingert]

The discussion should move to https://github.com/strophe/strophejs/issues