From 108328facbf0842c15fe9e8098c396d9b9d201ed Mon Sep 17 00:00:00 2001 From: Lachlan Sylvester Date: Thu, 9 Jul 2015 11:24:12 +1000 Subject: Update README - fix puma command and requiring environment from cabel/config.ru --- README.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 806f2a8273..fd1e2f8dc5 100644 --- a/README.md +++ b/README.md @@ -15,7 +15,7 @@ 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. So +a logical unit of work, similar to what a controller does in a regular MVC setup. So you may have a `ChatChannel` and a `AppearancesChannel`. The consumer can be subscribed to either or to both. At the very least, a consumer should be subscribed to one channel. @@ -26,7 +26,7 @@ could subscribe to multiple chat rooms at the same time. (And remember that a ph have multiple consumers, one per tab/device open to your connection). Each channel can then again be streaming zero or more broadcastings. A broadcasting is a -pubsub link where anything transmitted by the broadcaster is sent directly to the channel +pubsub link where anything transmitted by the broadcaster is sent directly to the channel subscribers who are streaming that named broadcasting. As you can see, this is a fairly deep architectural stack. There's a lot of new terminology @@ -148,7 +148,7 @@ We then link `App.appearance#appear` to `AppearanceChannel#appear(data)`. This i channel instance will automatically expose the public methods declared on the class (minus the callbacks), so that these can be reached as remote procedure calls via `App.appearance#perform`. -Finally, we expose `App.appearance` to the machinations of the application itself by hooking the `#appear` call into the +Finally, we expose `App.appearance` to the machinations of the application itself by hooking the `#appear` call into the Turbolinks `page:change` callback and allowing the user to click a data-behavior link that triggers the `#away` call. @@ -234,7 +234,7 @@ application. The recommended basic setup is as follows: ```ruby # cable/config.ru -require ::File.expand_path('../config/environment', __FILE__) +require ::File.expand_path('../../config/environment', __FILE__) Rails.application.eager_load! require 'action_cable/process/logging' @@ -245,7 +245,7 @@ run ActionCable.server Then you start the server using a binstub in bin/cable ala: ``` #!/bin/bash -bundle exec puma cable/config.ru -p 28080 +bundle exec puma -p 28080 cable/config.ru ``` That'll start a cable server on port 28080. Remember to point your client-side setup against that using something like: @@ -268,7 +268,7 @@ The Ruby side of things is built on top of [faye-websocket](https://github.com/f ## Deployment Action Cable is powered by a combination of EventMachine and threads. The -framework plumbing needed for connection handling is handled in the +framework plumbing needed for connection handling is handled in the EventMachine loop, but the actual channel, user-specified, work is handled in a normal Ruby thread. This means you can use all your regular Rails models with no problem, as long as you haven't committed any thread-safety sins. -- cgit v1.2.3