Skip to content
This repository has been archived by the owner on Dec 7, 2018. It is now read-only.

Refactor out EventMachine dependencies. #201

Open
digitalextremist opened this issue Jul 9, 2015 · 4 comments
Open

Refactor out EventMachine dependencies. #201

digitalextremist opened this issue Jul 9, 2015 · 4 comments
Milestone

Comments

@digitalextremist
Copy link
Member

Even though Celluloid and EventMachine are mutually exclusive, when Reel is installed, EventMachine comes along, because whether used or not, websocket-driver and other faye-* gems bring in an EventMachine dependency. This has affected actioncable also, through faye-* dependencies, and it is being addressed in this thread: rails/actioncable#16

In our next release bringing in HTTP/2 ( #198 ) we need to also refactor out dependencies which bring in EventMachine, whether it be used or not, and provide complete Celluloid::IO support for websockets, by refactoring the faye-* gems in parallel with this next release.

This will be achieved one of two ways:

  1. Working with @jcoglan to remove EventMachine in a version of his gems.
  2. Fork and refactor the faye-* gems as Celluloid::WebSocket which would also solve our need to bring celluloid-websocket-client back up to speed with the faye-* gems.

/cc: @tarcieri, @dhh, @jcoglan, @kenichi, @jasonayre

@digitalextremist digitalextremist added this to the 0.6.5 milestone Jul 9, 2015
@jcoglan
Copy link

jcoglan commented Jul 9, 2015

faye-websocket depends on EM but websocket-driver does not. The intention was always for websocket-driver to allow easy WebSocket integration into other I/O stacks.

@Asmod4n
Copy link
Contributor

Asmod4n commented Jul 9, 2015

websocket-driver is also quite easy to integrate into a celluloid-io loop: https://gist.github.com/Asmod4n/241c84ef31df921b31e9/c15bd4e3be2efd261f325d18eec126f1e9649b62

@digitalextremist
Copy link
Member Author

Thanks @jcoglan, that makes sense and explains what I've been seeing. EM is only listed as a development dependency for websocket-driver I now see. And agreed, @Asmod4n. I've seen and worked on several implementations like that. Thinking out loud...

Maybe we ought to extract all websocket code from Reel, and create reel-websocket both for client and server uses, fleshing out WebSocket::Driver in pure Celluloid::IO rather than focusing on the Rack approach being primary... of hijacking.

We can support hijacking in the reel-rack handler, but reel-websocketought to be a pure ruby, pure I/O base for that. Thenreel-websocketcan be used byReelitself andAngelo... half as a standardized "Celluloid WebSocket" and half as aWebSocket::Driver` abstraction layer.

@jcoglan
Copy link

jcoglan commented Jul 9, 2015

@digitalextremist Yep, EM is only used to run the example in the websocket-driver repo, it's not a runtime dep.

@digitalextremist digitalextremist modified the milestones: 0.6.5, 1.0 Feb 16, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants