pub/sub terminology: listeners are now subscribers, senders are publi…

…shers.

It's more sensible that way.

protocol.txt

@@ -1,4 +1,4 @@
-Simplish HTTP Push Relay Protocol, Rev. 2.1
+Simplish HTTP Push Relay Protocol, Rev. 2.2
 
 1. Introduction
 1.1 Purpose
@@ -25,18 +25,18 @@ participants in, and objects of, this protocol:
   client
     A program that initiates TCP/IP connections with the HTTP server for the 
     purpose of sending HTTP requests.
-  listener
+  subscriber
     A client that sends HTTP requests, which it expects could be long-held, 
     for the purposes of receiving some message when it becomes available. A 
-    listener receives at most one message per request.
-  sender
+    subscriber receives at most one message per request.
+  publisher
     A client that notifies the server of the availability of messages for some
-    listener.
+    subscriber.
   message
-    Application specific data that is relayed from a sender to a receiver.
+    Application specific data that is relayed from a publisher to a receiver.
   channel
-    An isolated channel of communication between some senders and some 
-    listeners privy to its existence. 
+    An isolated channel of communication between some publishers and some 
+    subscribers privy to its existence. 
   channel id
     A unique identifier for a channel.
   location
@@ -45,32 +45,32 @@ participants in, and objects of, this protocol:
 2. Requirements
 2.1 Server Requirements
 The HTTP server MUST have a mechanism of specifying a url, or a set of urls as
-sender and receiver locations. All connections to the sender location MUST be
-treated as senders, all to the receiver location as receivers.
-Furthermore, the server MUST implement a mechanism for identifying each sender
+publisher and receiver locations. All connections to the publisher location MUST be
+treated as publishers, all to the receiver location as receivers.
+Furthermore, the server MUST implement a mechanism for identifying each publisher
 and receiver request with an id. This MAY, for example, be a url parameter 
 (/foo/?id=123) or a cookie (although methods of channel identification other 
 than those using the url are inadvisable).
-The server MUST accept requests on sender locations and respond to them 
-immediately. It MUST also accept requests on listener locations, but need not 
+The server MUST accept requests on publisher locations and respond to them 
+immediately. It MUST also accept requests on subscriber locations, but need not 
 respond immediately.
 
 2.2 Client Requirements
-All client HTTP requests must be valid. Listener clients must have a caching 
+All client HTTP requests must be valid. Subscriber clients must have a caching 
 mechanism that appropriately reacts to Last-Modified and Etag response headers 
 (web browsers, for example).
 
 2.2 The Channel ID
 It is not the responsibility of the server to generate IDs.
 
 3 Server Operation
-A sender request functions as notification to the server of a message to send 
-to a listener over some channel. A listener request notifies the server of the 
-listener's intent to receive a message.
+A publisher request functions as notification to the server of a message to send 
+to a subscriber over some channel. A subscriber request notifies the server of the 
+subscriber's intent to receive a message.
 
-3.1 The Listener
-The server MUST accept all valid HTTP requests to the listener location.
-The server, when sent a listener request, MUST satisfy all of the following
+3.1 The Subscriber
+The server MUST accept all valid HTTP requests to the subscriber location.
+The server, when sent a subscriber request, MUST satisfy all of the following
 conditions:
   - GET requests with no If-Modified-Since header will be responded to with the
     oldest available message in the channel, or will be long-held.
@@ -79,46 +79,46 @@ conditions:
     headers), or will be long-held. The If-None-Match header may also be used.
   - A GET request that is being long-held MUST be responded to with EITHER:
      - 200 OK when a message is received. The Content-Type header MUST be set
-       to the same header of the original sender request. 
+       to the same header of the original publisher request. 
      - 410 Gone if the channel becomes unavailable (i.e. has been deleted).
-     - 409 Conflict if another listener has conflicted with this request.
+     - 409 Conflict if another subscriber has conflicted with this request.
      - 403 Forbidden
   - All other request methods SHOULD be responded to with a 405 Method Not 
     Allowed status.
-In addition, the server MUST do one of the following when sent a valid listener
+In addition, the server MUST do one of the following when sent a valid subscriber
 GET request:
- - All other long-held listener requests will be send a 409 Conflict response.
+ - All other long-held subscriber requests will be send a 409 Conflict response.
    (last-in-first-out)
  - All but the oldest (including this) request will be sent a 409 Conflict
    response. (first-in-last-out)
  - No additional actions are performed. (broadcast)
 The server SHOULD make this selection configurable.
 
-3.2 The Sender
-The server MUST accept all valid HTTP requests to the sender location.
-The server, when sent a sender request, MUST satisfy all of the following
+3.2 The Publisher
+The server MUST accept all valid HTTP requests to the publisher location.
+The server, when sent a publisher request, MUST satisfy all of the following
 conditions:
   - GET requests receive a 200 OK response for known channels and a 
     404 Not Found otherwise.
   - PUT requests receive a 200 OK response. The request creates a channel if 
     no channel with the given channel id exists.
   - DELETE requests receive a 200 OK if the channel identified by the 
-    channel id exists and has been completely deleted. All listeners MUST 
+    channel id exists and has been completely deleted. All subscribers MUST 
     have been sent a 410 Gone response. Requests for nonexistent channels MUST
     be responded to with a 404 Not Found.
   - POST requests are used to send messages. The request MAY contain a body in
     any encoding representing a message to be sent over the channel. The message
-    MUST be immediately delivered to all currently long-held listener requests.
+    MUST be immediately delivered to all currently long-held subscriber requests.
     Additionally, the message MAY be stored for future retrieval and the oldest
     message stored for the channel MAY be deleted.
     A POST request MUST be replied to with a 201 Created if there were any
-    long-held listeners that have been sent this message, and with a 
+    long-held subscribers that have been sent this message, and with a 
     202 Accepted otherwise.
     The Content-Type header of the request MUST be forwarded with the message.
-Message storage limits SHOULD be configurable. Sender locations SHOULD be 
+Message storage limits SHOULD be configurable. publisher locations SHOULD be 
 configurable to allow foregoing message storage on POST requests.
 All 200-level responses MUST, in the response body, contain information about 
 the applicable channel. This information MAY contain the number of stored
-messages and the number of listeners' requests being long-held prior to this 
+messages and the number of subscribers' requests being long-held prior to this 
 request. The server MAY implement a content-negotiation scheme for this 
 information.