typos

Author: AndrewBurian

README.md

@@ -24,7 +24,7 @@ The `Stream` object implements an `http.Handler` for you so it can be registered
 You got it! What do you need?
 
 ## Multiplexing / Topics / Rooms / Channels
-We call them "topics" but the gist is the same. All Clients always recieve `Broadcast` events, but you can `Publish` events to a specific topic, and then only clients that have `Subscribe`d to that topic will recieve the event.
+We call them "topics" but the gist is the same. All Clients always receive `Broadcast` events, but you can `Publish` events to a specific topic, and then only clients that have `Subscribe`d to that topic will receive the event.
 
 ```go
 stream.Subscribe("weather", myClient)
@@ -59,7 +59,7 @@ http.ListenAndServe(":8080", catsHandler)
 Use the stream's `Register`, `Subscribe`, `Remove`, `Unsubscribe`, and `CloseTopic` functions to control which clients are registered where.
 
 ## Tell me when clients connect
-Register a callback for the `Stream` to envoke everytime a new client connects with `Stream.ClientConnectHook`. It'll give you a handle to the resulting Client and the http request that created it, letting you do whatever you please.
+Register a callback for the `Stream` to invoke every time a new client connects with `Stream.ClientConnectHook`. It'll give you a handle to the resulting Client and the http request that created it, letting you do whatever you please.
 
 ```go
 stream := eventsource.NewStream()
@@ -71,13 +71,13 @@ stream.ClientConnectHook(func(r *http.Requset, c *eventsource.Client){
 })
 ```
 
-The callback will be on the same goroutine as the incoming web request that created it, but the Client is live and functioning so it'll start recieving broadcasts and publishments immediately before your callback has returned.
+The callback will be on the same goroutine as the incoming web request that created it, but the Client is live and functioning so it'll start receiving broadcasts and publications immediately before your callback has returned.
 
 ## Graceful shutdown
-The stream's `Shutdown` command will unsubscribe and disconnect all connected clients. However the `Stream` itself is not running any background routines, and may continue to register new clients if it's still registed as an http handler.
+The stream's `Shutdown` command will unsubscribe and disconnect all connected clients. However the `Stream` itself is not running any background routines, and may continue to register new clients if it's still registered as an http handler.
 
 ## Get out of my way
-Fine! The `Stream` object is entirely convinience. It runs no background routines and does no special handling. It just adds the topics abstraction and calls `NewClient` for you when it's connected to. Feel free not to use it.
+Fine! The `Stream` object is entirely convenience. It runs no background routines and does no special handling. It just adds the topics abstraction and calls `NewClient` for you when it's connected to. Feel free not to use it.
 
 # More control of the `Client`
 You betcha.
@@ -101,12 +101,12 @@ func ServeHTTP(w http.ResponseWriter, r *http.Request) {
 Letting the http handler routine that created the Client return may cause the underlying connection to be closed by the server. Since `NewClient` does not block, use `Wait` to block until the client is shutdown.
 
 ## Shutdown the client
-The client's `Shutdown` function terminates the background routine and marks the client as closed. It does not actually sever the connection. It does unblock any routines waiting on `Wait`, which assuming the main http hander routine was waiting there, will cause the connection to close as it returns.
+The client's `Shutdown` function terminates the background routine and marks the client as closed. It does not actually sever the connection. It does unblock any routines waiting on `Wait`, which assuming the main http handler routine was waiting there, will cause the connection to close as it returns.
 
 Attempts to `Send` events to a client after it has been shutdown will result in an error
 
 # More control of Events
-Events are the most critical part of the library, and are the most versitile.
+Events are the most critical part of the library, and are the most versatile.
 
 ## Write my own events from scratch
 Events implement the `io.ReadWriter` interface so that data can be written to it from practically any source. However the `Write` interface _does not_ write an entire event in wire format. It writes the provided buffer into `data:` sections in the resulting event.
@@ -135,7 +135,7 @@ newEvent.WriteRaw(evData)             // that will work
 newEvent.AppendData("Moar")           // ... and you ruined it
 ```
 
-Use `Clone` to create a perfect deep copy that survives further mutation. Though this is less efficient in memeory.
+Use `Clone` to create a perfect deep copy that survives further mutation. Though this is less efficient in memory.
 
 ## Create events more easily
 Since you will probably be creating more than just a few events, the `EventFactory` interface and a couple helper factories and functions have been provided to speed things up.

event.go

@@ -119,7 +119,7 @@ func (e *Event) Write(p []byte) (int, error) {
 }
 
 // WriteString adds string data to the event.
-// Equivilant to calling Write([]byte(string))
+// Equivalent to calling Write([]byte(string))
 func (e *Event) WriteString(p string) {
 	// split event on newlines
 	split := strings.Split(p, "\n")

stream.go

@@ -4,7 +4,7 @@ Package eventsource is a library for dealing with server sent events in Go.
 The library attempts to make as few assumptions as possible about how your apps
 will be written, and remains as generic as possible while still being simple and useful.
 
-The three core obects to the library are Clients, Events, and Streams.
+The three core objects to the library are Clients, Events, and Streams.
 
 Client wraps an HTTP connection, and runs a worker routine to send events to the connected
 client in a thread-safe way. It gracefully handles client disconnects.
@@ -14,7 +14,7 @@ it to wire format to send. Events are not thread-safe by themselves.
 
 Stream is an abstraction for 0 or more Client connections, and adds some multiplexing and filtering
 on top of the Client. It also can act as an http.Handler to automatically register inbound client
-connections and disconnectinos.
+connections and disconnections.
 
 A quick example of a simple sever that broadcasts a "tick" event every second