-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a server implementation #32
Comments
I'm planning on implementing this. Here are some thoughts on requirements: Requirements:
@1c3t3a Thoughts? Have anything to add or preferences on how/frameworks they are implemented in? |
Hei @nshaaban-cPacket this sounds great! I think a server implementation is definitely the most needed feature for this crate. I think the basic requirements are a full match of what I would expect, especially websocket support is important as long-polling is nearly never used anymore, but still needs support as the backup transport layer. Looking at the dependencies I would think it might be a good idea to reuse all transport related crates and not add too many new ones as this would probably bloat our build a lot. Looking at the http server, I would suggest to use |
Sounds good. Thank you for having a good base to start with! And with such good documentation! Did you want to continue to support sync and full async? If so there may need to be some internal organization which makes as much code as reasonably beneficial async, while still keeping sync endpoints functional without duplicating code. |
There is a rust server implementation already in development here: https://github.com/totodore/socketioxide |
Until now this crate only provides a socketio client. A possible server implementation could use the same packet parser and maybe parts of the engine.io socket.
The text was updated successfully, but these errors were encountered: