Websockets -> WebSocket spelling [ci skip]
This commit is contained in:
parent
ee16ca8990
commit
0dc7f80177
18
README.md
18
README.md
|
@ -1,7 +1,7 @@
|
|||
# Action Cable – Integrated websockets for Rails
|
||||
# Action Cable – Integrated WebSockets for Rails
|
||||
[![Build Status](https://travis-ci.org/rails/actioncable.svg)](https://travis-ci.org/rails/actioncable)
|
||||
|
||||
Action Cable seamlessly integrates websockets with the rest of your Rails application.
|
||||
Action Cable seamlessly integrates WebSockets with the rest of your Rails application.
|
||||
It allows for real-time features to be written in Ruby in the same style
|
||||
and form as the rest of your Rails application, while still being performant
|
||||
and scalable. It's a full-stack offering that provides both a client-side
|
||||
|
@ -12,9 +12,9 @@ domain model written with ActiveRecord or your ORM of choice.
|
|||
## Terminology
|
||||
|
||||
A single Action Cable server can handle multiple connection instances. It has one
|
||||
connection instance per websocket connection. A single user may have multiple
|
||||
websockets open to your application if they use multiple browser tabs or devices.
|
||||
The client of a websocket connection is called the consumer.
|
||||
connection instance per WebSocket connection. A single user may have multiple
|
||||
WebSockets open to your application if they use multiple browser tabs or devices.
|
||||
The client of a WebSocket connection is called the consumer.
|
||||
|
||||
Each consumer can in turn subscribe to multiple cable channels. Each channel encapsulates
|
||||
a logical unit of work, similar to what a controller does in a regular MVC setup. For example, you could have a `ChatChannel` and a `AppearancesChannel`, and a consumer could be subscribed to either
|
||||
|
@ -169,8 +169,8 @@ Turbolinks `page:change` callback and allowing the user to click a data-behavior
|
|||
|
||||
### Channel example 2: Receiving new web notifications
|
||||
|
||||
The appearance example was all about exposing server functionality to client-side invocation over the websocket connection.
|
||||
But the great thing about websockets is that it's a two-way street. So now let's show an example where the server invokes
|
||||
The appearance example was all about exposing server functionality to client-side invocation over the WebSocket connection.
|
||||
But the great thing about WebSockets is that it's a two-way street. So now let's show an example where the server invokes
|
||||
action on the client.
|
||||
|
||||
This is a web notification channel that allows you to trigger client-side web notifications when you broadcast to the right
|
||||
|
@ -336,7 +336,7 @@ The above will start a cable server on port 28080. Remember to point your client
|
|||
|
||||
### In app
|
||||
|
||||
If you are using a threaded server like Puma or Thin, the current implementation of ActionCable can run side-along with your Rails application. For example, to listen for websocket requests on `/websocket`, match requests on that path:
|
||||
If you are using a threaded server like Puma or Thin, the current implementation of ActionCable can run side-along with your Rails application. For example, to listen for WebSocket requests on `/websocket`, match requests on that path:
|
||||
|
||||
```ruby
|
||||
# config/routes.rb
|
||||
|
@ -359,7 +359,7 @@ We'll get all this abstracted properly when the framework is integrated into Rai
|
|||
## Dependencies
|
||||
|
||||
Action Cable is currently tied to Redis through its use of the pubsub feature to route
|
||||
messages back and forth over the websocket cable connection. This dependency may well
|
||||
messages back and forth over the WebSocket cable connection. This dependency may well
|
||||
be alleviated in the future, but for the moment that's what it is. So be sure to have
|
||||
Redis installed and running.
|
||||
|
||||
|
|
|
@ -4,8 +4,8 @@ require 'action_cable/version'
|
|||
Gem::Specification.new do |s|
|
||||
s.name = 'actioncable'
|
||||
s.version = ActionCable::VERSION
|
||||
s.summary = 'Websockets framework for Rails.'
|
||||
s.description = 'Structure many real-time application concerns into channels over a single websockets connection.'
|
||||
s.summary = 'WebSocket framework for Rails.'
|
||||
s.description = 'Structure many real-time application concerns into channels over a single WebSocket connection.'
|
||||
s.license = 'MIT'
|
||||
|
||||
s.author = ['Pratik Naik', 'David Heinemeier Hansson']
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
module ActionCable
|
||||
module Channel
|
||||
# The channel provides the basic structure of grouping behavior into logical units when communicating over the websocket connection.
|
||||
# The channel provides the basic structure of grouping behavior into logical units when communicating over the WebSocket connection.
|
||||
# You can think of a channel like a form of controller, but one that's capable of pushing content to the subscriber in addition to simply
|
||||
# responding to the subscriber's direct requests.
|
||||
#
|
||||
|
|
|
@ -2,7 +2,7 @@ require 'action_dispatch/http/request'
|
|||
|
||||
module ActionCable
|
||||
module Connection
|
||||
# For every websocket the cable server is accepting, a Connection object will be instantiated. This instance becomes the parent
|
||||
# For every WebSocket the cable server is accepting, a Connection object will be instantiated. This instance becomes the parent
|
||||
# of all the channel subscriptions that are created from there on. Incoming messages are then routed to these channel subscriptions
|
||||
# based on an identifier sent by the cable consumer. The Connection itself does not deal with any specific application logic beyond
|
||||
# authentication and authorization.
|
||||
|
@ -37,8 +37,8 @@ module ActionCable
|
|||
# established for that current_user (and potentially disconnect them if the user was removed from an account). You can declare as many
|
||||
# identification indexes as you like. Declaring an identification means that a attr_accessor is automatically set for that key.
|
||||
#
|
||||
# Second, we rely on the fact that the websocket connection is established with the cookies from the domain being sent along. This makes
|
||||
# it easy to use signed cookies that were set when logging in via a web interface to authorize the websocket connection.
|
||||
# Second, we rely on the fact that the WebSocket connection is established with the cookies from the domain being sent along. This makes
|
||||
# it easy to use signed cookies that were set when logging in via a web interface to authorize the WebSocket connection.
|
||||
#
|
||||
# Finally, we add a tag to the connection-specific logger with name of the current user to easily distinguish their messages in the log.
|
||||
#
|
||||
|
@ -65,7 +65,7 @@ module ActionCable
|
|||
@started_at = Time.now
|
||||
end
|
||||
|
||||
# Called by the server when a new websocket connection is established. This configures the callbacks intended for overwriting by the user.
|
||||
# Called by the server when a new WebSocket connection is established. This configures the callbacks intended for overwriting by the user.
|
||||
# This method should not be called directly. Rely on the #connect (and #disconnect) callback instead.
|
||||
def process
|
||||
logger.info started_request_message
|
||||
|
@ -87,17 +87,17 @@ module ActionCable
|
|||
if websocket.alive?
|
||||
subscriptions.execute_command ActiveSupport::JSON.decode(data_in_json)
|
||||
else
|
||||
logger.error "Received data without a live websocket (#{data_in_json.inspect})"
|
||||
logger.error "Received data without a live WebSocket (#{data_in_json.inspect})"
|
||||
end
|
||||
end
|
||||
|
||||
# Send raw data straight back down the websocket. This is not intended to be called directly. Use the #transmit available on the
|
||||
# Send raw data straight back down the WebSocket. This is not intended to be called directly. Use the #transmit available on the
|
||||
# Channel instead, as that'll automatically address the correct subscriber and wrap the message in JSON.
|
||||
def transmit(data)
|
||||
websocket.transmit data
|
||||
end
|
||||
|
||||
# Close the websocket connection.
|
||||
# Close the WebSocket connection.
|
||||
def close
|
||||
websocket.close
|
||||
end
|
||||
|
@ -124,7 +124,7 @@ module ActionCable
|
|||
|
||||
|
||||
protected
|
||||
# The request that initiated the websocket connection is available here. This gives access to the environment, cookies, etc.
|
||||
# The request that initiated the WebSocket connection is available here. This gives access to the environment, cookies, etc.
|
||||
def request
|
||||
@request ||= begin
|
||||
environment = Rails.application.env_config.merge(env) if defined?(Rails.application) && Rails.application
|
||||
|
@ -132,7 +132,7 @@ module ActionCable
|
|||
end
|
||||
end
|
||||
|
||||
# The cookies of the request that initiated the websocket connection. Useful for performing authorization checks.
|
||||
# The cookies of the request that initiated the WebSocket connection. Useful for performing authorization checks.
|
||||
def cookies
|
||||
request.cookie_jar
|
||||
end
|
||||
|
@ -201,7 +201,7 @@ module ActionCable
|
|||
'Started %s "%s"%s for %s at %s' % [
|
||||
request.request_method,
|
||||
request.filtered_path,
|
||||
websocket.possible? ? ' [Websocket]' : '',
|
||||
websocket.possible? ? ' [WebSocket]' : '',
|
||||
request.ip,
|
||||
Time.now.to_default_s ]
|
||||
end
|
||||
|
@ -209,7 +209,7 @@ module ActionCable
|
|||
def finished_request_message
|
||||
'Finished "%s"%s for %s at %s' % [
|
||||
request.filtered_path,
|
||||
websocket.possible? ? ' [Websocket]' : '',
|
||||
websocket.possible? ? ' [WebSocket]' : '',
|
||||
request.ip,
|
||||
Time.now.to_default_s ]
|
||||
end
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
module ActionCable
|
||||
module Connection
|
||||
# Allows us to buffer messages received from the websocket before the Connection has been fully initialized and is ready to receive them.
|
||||
# Allows us to buffer messages received from the WebSocket before the Connection has been fully initialized and is ready to receive them.
|
||||
# Entirely internal operation and should not be used directly by the user.
|
||||
class MessageBuffer
|
||||
def initialize(connection)
|
||||
|
@ -50,4 +50,4 @@ module ActionCable
|
|||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
@ -18,7 +18,7 @@ module ActionCable
|
|||
connections.delete connection
|
||||
end
|
||||
|
||||
# Websocket connection implementations differ on when they'll mark a connection as stale. We basically never want a connection to go stale, as you
|
||||
# WebSocket connection implementations differ on when they'll mark a connection as stale. We basically never want a connection to go stale, as you
|
||||
# then can't rely on being able to receive and send to it. So there's a 3 second heartbeat running on all connections. If the beat fails, we automatically
|
||||
# disconnect.
|
||||
def setup_heartbeat_timer
|
||||
|
@ -34,4 +34,4 @@ module ActionCable
|
|||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
@ -22,7 +22,7 @@ Celluloid.logger = Logger.new(StringIO.new)
|
|||
|
||||
class Faye::WebSocket
|
||||
# We don't want Faye to start the EM reactor in tests because it makes testing much harder.
|
||||
# We want to be able to start and stop EW loop in tests to make things simpler.
|
||||
# We want to be able to start and stop EM loop in tests to make things simpler.
|
||||
def self.ensure_reactor_running
|
||||
# no-op
|
||||
end
|
||||
|
|
Loading…
Reference in New Issue