Skip to content
This repository has been archived by the owner on Aug 25, 2022. It is now read-only.

Little patch for Socket 1.0.x - Working on my nRelay Project. #53

Closed
wants to merge 4 commits into from
Closed

Conversation

lalmat
Copy link

@lalmat lalmat commented Jul 26, 2014

I spent a little time today to have Elephant.IO working with Socket 1.0.x.
Only tested with the default namespace "/" but it works for me

Hope it helps !
Thanks for this project.

@gmajoulet
Copy link
Contributor

I can't wait to test it, we already tried a quick patch like your and were able to connect the server, but not to emit any event. Thanks. :)

@lalmat
Copy link
Author

lalmat commented Jul 26, 2014

Thanks, I'll do it.

@lalmat
Copy link
Author

lalmat commented Jul 26, 2014

Job done !

I renamed the old "TYPE_" to "EIO_" to follow the Engine.IO Protocol, and I added "SIO_" constant to follow Socket.IO. I think it's will be easier to understand.

@newelement
Copy link

This patch is working well for me. Thanks for the patch!

@ShawnOY
Copy link

ShawnOY commented Jul 28, 2014

Path is working for me too .
Nice job !

@guillaumepotier
Copy link
Member

Indeed. Patch seems to work like a charm!

I think this is time for v2, a whole refacto like you initiated in #54, there are plenty good ideas, thanks ;)

I think we'll need though to support socket.io 0.x and 1.x in an elegant way, any idea how?

Best

# *.sublime-project

#sftp configuration file
sftp-config.json
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All these have nothing to do in a .gitignore (project wise), it should be in your global .gitignore. Otherwise, we should support everything... And I don't think that this is really possible. :D

@lalmat
Copy link
Author

lalmat commented Jul 28, 2014

Sorry for the .gitignore and the require.

At work, as we work with the same IDE (Eclipse or SublimeText) we always add this things in gitignore and it's pretty useful (at work...)

For the require, i'm not a composer user... I think i should learn how to use it :)

Thanks for the feedback.

@lalmat
Copy link
Author

lalmat commented Jul 29, 2014

Guillaume,

You said that Elephant.IO need to support 0.9.x and 1.0.x, but is it possible to ask the server during the handshake to know in which version of Socket.IO it use ? If not, I think it is better to stick to the current Socket.IO protocol.

For 0.9 Socket.IO versions, user should use the actual Elephant.IO which is doing his job very well.

As socket.io 1.0.x break the backward compatibility with previous versions, this let me belive that Elephant.IO should do the same.

There's some functionnality in Socket.IO not supported yet by my Elephant.IO fork. Maybe the community can focus on a full support of them (like the binary handshake and transfert).

What's your mind about it ?

@Taluu
Copy link
Contributor

Taluu commented Jul 29, 2014

About the refactoring, I was pondering to let the user decide which version should be targetted (1.x, 0.x, ... etc). Or even better : to let Elephant.io not being restricted to Socket.io only.

The thing about the handshake is a good idea (maybe a Socket.io factory ?) though. But I don't think it should be implemented into the core of Elephant.io.

@guillaumepotier
Copy link
Member

Maybe Elephant.io 3.0 should focus on Socket.io 1.x at the moment, and encourage users to use 2.x current version if they want to use socket.io 0.9.x.

On the other hand, what @Taluu suggested above is quite interesting, it might be useful to analyse deeper how socket.io handle websocket payloads to communicate and support various versions that way (and maybe not only socket.io but why not sock.js, etc..)

Do you have any insights on that point @lalmat ?

Best

@lalmat
Copy link
Author

lalmat commented Jul 31, 2014

I've just seen that @Taluu wish to support multiple engine and I think it's a good idea, I belive that having a multi protocol websocket lib in PHP will be a killer feature.

How do you project to split the code ? One repo by engine (like nodejs philosophy) or will you put all the stuff in the same repo ?

@Taluu
Copy link
Contributor

Taluu commented Jul 31, 2014

I was thinking about having one repo with some core engines (such as Socket.io 0.x and 1.x), and leave the window open for the guys who want to implement something else. But the support will be only on the core engines though... Even if a list (like on a wiki or something like that) could be made to view other engines. :)

@guillaumepotier
Copy link
Member

Agreed with @Taluu would be a mess to maintain having various repos. Lib is quite small and having 2-3 supported official engines won't be too big here.

@Taluu
Copy link
Contributor

Taluu commented Aug 18, 2014

Closing this pull request as the 3.0 is now getting towards a final release, and as the new version was pretty much based on your work.

Thanks ! :)

@Taluu Taluu closed this Aug 18, 2014
// wait 100ms before closing connexion
usleep(100*1000);
if ($this->read) {
if ($this->read() != '1::') {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think '1::' is socket.io v0.9 format. In my case, server responded "40" to client message "52".

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants