Strophe.js needs a roadmap for websockets about strophejs HOT 29 OPEN

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.

from strophejs.

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

from strophejs.

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

from strophejs.

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

from strophejs.

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.

from strophejs.

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

from strophejs.

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

from strophejs.

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?

from strophejs.

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.

from strophejs.

@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?

from strophejs.

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

from strophejs.

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.

from strophejs.

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? :)

from strophejs.

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.

from strophejs.

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"

from strophejs.

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

from strophejs.

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

from strophejs.

Sure, sorry ;)

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

from strophejs.

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

from strophejs.

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

from strophejs.

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

from strophejs.

@Gordin: sounds good.

from strophejs.

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

from strophejs.

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

from strophejs.

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?

from strophejs.

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

from strophejs.

@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

from strophejs.

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.

from strophejs.

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

from strophejs.