Websockets -> WebSocket spelling [ci skip]

README.md

-# 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.
 

actioncable.gemspec

@@ -4,8 +4,8 @@
 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']

lib/action_cable/channel/base.rb

 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.
     #

lib/action_cable/connection/base.rb

@@ -2,7 +2,7 @@
 
 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 Connection
     # 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 @@ def initialize(server, env)
         @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 @@ def receive(data_in_json)
         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 @@ def beat
 
 
       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 @@ def request
           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 @@ def started_request_message
           '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 @@ def started_request_message
         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

lib/action_cable/connection/message_buffer.rb

 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 @@ def receive_buffered_messages
         end
     end
   end
-end
\ No newline at end of file
+end

lib/action_cable/server/connections.rb

@@ -18,7 +18,7 @@ def remove_connection(connection)
         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 @@ def open_connections_statistics
       end
     end
   end
-end
\ No newline at end of file
+end

test/test_helper.rb

@@ -22,7 +22,7 @@
 
 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