Examine "next" branch

ChangeLog.md

@@ -23,18 +23,21 @@ Upcoming
 Unscheduled
 -----------
 
-* Support encoding/serialization request bodies, analogous to the
-  decoding/de-serialization for response bodies which is done in the
-  Content class
-
-    - This probably means reorganizing the Content class, perhaps adding
-      another level of structure
-    - Find a convenient way for the user to specify request-body
-      content-type. Maybe add a `content_type=` parameter to `put()` et
-      al?
-
-    - Does GitHub support this? It should. And if so, we should use it
-      by default
+* Support reusing TCP connections, and "pipelining" of requests, a la
+  RFC 2068, Sect 8.1, L2377
+
+    - The user must ask for pipelining, and supply a callback function
+      to be called after a response is received.
+    - Rename Client.request() -> Client.addRequest() (or such)
+    - Have Client.addRequest() check whether a persistent connection is
+      wanted, and save the entire request in a Client.pendingRequests
+      list in that case
+    - Create a new Client.sendRequests() method which the user may call
+      to send all requests up the pipeline. (It should work even if the
+      server does not support pipelining)
+    - Call the user-supplied callback whenever a request is received.
+      There are some concurrency issues here, and we may elect to call
+      the callback only after *all* requests are received.
 
 * Create a script to pack the basic module and any given set of
   service-specific classes as one file
@@ -88,6 +91,23 @@ v2.0
 * Support XML de-serialization. Python has (I think) built-in support
   for this
 
+* Support encoding/serialization request bodies, analogous to the
+  decoding/de-serialization for response bodies which is done in the
+  Content class
+
+    - This probably means reorganizing the Content class, perhaps adding
+      another level of structure
+    - Find a convenient way for the user to specify request-body
+      content-type. Maybe add a `content_type=` parameter to `put()` et
+      al?
+
+    - Does GitHub support this? It should. And if so, we should use it
+      by default
+
+* Parse Content-Type header correctly; make a dict of the
+  parameters (Content.ctypeParameters) available to the media-type
+  handlers
+
 v1.1.1
 ------
 

README.md

@@ -1,10 +1,10 @@
-# The Agnostic Github API
+# The Agnostic GitHub API
 *It doesn't know, and you don't care!*
 
 `agithub` is a REST API client tailored to https://api.github.com, with
 a transparent syntax which facilitates rapid prototyping. It's code is
 lightweight: easy to understand, modify, and integrate. It's most
-salient feature is that it doesn't know the Github API — but
+salient feature is that it doesn't know the GitHub API — but
 that doesn't matter, since it fully supports it *anyway*.
 
 While browsing the
@@ -28,12 +28,12 @@ can read the docs and immediately know how to do the examples via
 
 ## Example App
 
-1. First, instantiate a `Github` object, passing it your username and
+1. First, instantiate a `GitHub` object, passing it your username and
    password if an authenticated session is desired.
 
    ```python
-   >>> from agithub import Github
-   >>> g = Github('user', 'pass')
+   >>> from agithub import GitHub
+   >>> g = GitHub('user', 'pass')
    ```
 
 2. When you make a request, the status and response body are passed back
@@ -83,15 +83,15 @@ can read the docs and immediately know how to do the examples via
 
    You may find this useful — or not.
 
-6. Finally, `agithub` knows nothing at all about the Github API, and it
+6. Finally, `agithub` knows nothing at all about the GitHub API, and it
    won't second-guess you.
 
    ```python
    >>> g.funny.I.donna.remember.that.one.head()
    (404, {'message': 'Not Found'})
    ```
 
-   The error message you get is directly from Github's API. This gives
+   The error message you get is directly from GitHub's API. This gives
    you all of the information you need to survey the situation.
 
 7. If you need more information, the response headers of the previous
@@ -113,7 +113,7 @@ crop up:
 1. Networking Exceptions (from the `http` library). Catch these with
    `try .. catch` blocks, as you otherwise would.
 
-2. Github API errors. These means you're doing something wrong with the
+2. GitHub API errors. These means you're doing something wrong with the
    API, and they are always evident in the response's status. The API
    considerately returns a helpful error message in the JSON body.