[Rails-core] Re: feature request (with demo code): native websockets as controller callbacks.

[Boaz Segev]

I added code that automates the #broadcast to use a Redis server (if 
defined).

I think having these features in Rails, where a controller can respond to 
websocket events, is critical for moving forward.

Using middleware and dedicated event machines to handle parts of the 
application means that the developers are moving away from the framework 
and the code is less well organized and harder to maintain.

Having the framework respond to both RESTful requests and WebSocket 
requests, like in this experimental framework 
<https://github.com/boazsegev/anorexic>, feels essential in this worlds 
where http and webs apps act also as the backend for mobile apps and other 
advanced clients.

Feel free to ask any questions, I would love if these websocket features 
were assimilated in Rails.

On Wednesday, December 3, 2014 6:04:48 PM UTC-5, Boaz Segev wrote:
>
> Hi,
>
> I was thinking about this a lot and even found myself writing a whole server 
> / framework with native websocket support 
> <https://github.com/boazsegev/anorexic> to see what was possible.
>
> Websockets is far too complicated to to easily utilize in it's present 
> state, since using websockets in Rails applications requires Rack and 
> Middleware knowhow which is not expected from the average Rails developer 
> and isn't common.
>
> I propose adding support for native websockets within the Controller class 
> - by defining callback support for the following methods / events: 
> `pre_connect` (before protocol upgrade, for updating cookies and HTTP 
> data), `on_connect` (after protocol upgrade), `on_message(data)`, 
> `on_disconnect`.
>
> this also might require adding support for controller class instance 
> communication, assuming each connection has it's own controller instance - 
> this could allow us to broadcast messages and collect information from 
> other connections directly (without pulling on databases or setting up 
> flags)... I've managed an interesting solution within the `broadcast` and 
> `collect` methods in my experimental framework.
>
> If anyone thinks this is a good approach, please feel free to contact me 
> about adapting my code (or writing new code) for the Rails 5.0 release.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Re: feature request (with demo code): native websockets as controller callbacks.

[Boaz Segev]

Ha... that's probably true (lol)...

...It started as a pet project for myself - I was making a private joke at 
the expense of the 'Thin' server (which I love)...

:)


On Thursday, December 4, 2014 8:15:19 PM UTC+2, Kunal Shah wrote:
>
> Boaz,
>
> You really need to rename your project. It's 2014 almost 2015, we have to 
> be wiser than this.
>
> Respectfully
> Kunal
>
> On Wednesday, December 3, 2014 6:04:48 PM UTC-5, Boaz Segev wrote:
>>
>> Hi,
>>
>> I was thinking about this a lot and even found myself writing a whole server 
>> / framework with native websocket support 
>> <https://github.com/boazsegev/anorexic> to see what was possible.
>>
>> Websockets is far too complicated to to easily utilize in it's present 
>> state, since using websockets in Rails applications requires Rack and 
>> Middleware knowhow which is not expected from the average Rails developer 
>> and isn't common.
>>
>> I propose adding support for native websockets within the Controller 
>> class - by defining callback support for the following methods / events: 
>> `pre_connect` (before protocol upgrade, for updating cookies and HTTP 
>> data), `on_connect` (after protocol upgrade), `on_message(data)`, 
>> `on_disconnect`.
>>
>> this also might require adding support for controller class instance 
>> communication, assuming each connection has it's own controller instance - 
>> this could allow us to broadcast messages and collect information from 
>> other connections directly (without pulling on databases or setting up 
>> flags)... I've managed an interesting solution within the `broadcast` and 
>> `collect` methods in my experimental framework.
>>
>> If anyone thinks this is a good approach, please feel free to contact me 
>> about adapting my code (or writing new code) for the Rails 5.0 release.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] feature request (with demo code): native websockets as controller callbacks.

[Boaz Segev]

Hi,

I was thinking about this a lot and even found myself writing a whole server 
/ framework with native websocket support 
 to see what was possible.

Websockets is far too complicated to to easily utilize in it's present 
state, since using websockets in Rails applications requires Rack and 
Middleware knowhow which is not expected from the average Rails developer 
and isn't common.

I propose adding support for native websockets within the Controller class 
- by defining callback support for the following methods / events: 
`pre_connect` (before protocol upgrade, for updating cookies and HTTP 
data), `on_connect` (after protocol upgrade), `on_message(data)`, 
`on_disconnect`.

this also might require adding support for controller class instance 
communication, assuming each connection has it's own controller instance - 
this could allow us to broadcast messages and collect information from 
other connections directly (without pulling on databases or setting up 
flags)... I've managed an interesting solution within the `broadcast` and 
`collect` methods in my experimental framework.

If anyone thinks this is a good approach, please feel free to contact me 
about adapting my code (or writing new code) for the Rails 5.0 release.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.