Consider what if any planned work should still be done and capture it in issues

[gene1wood]

The Changelog says

• The todo list for the project is in the changelog
• upcoming releases are at the top
• the tip of the maint branch is the latest stable branch

I'm planning to

• change the Changelog format to the Keepachangelog standard
• Use an Unreleased section at the top but get rid of Unscheduled, Upcoming and version numbers that don't yet exist.

Here's what the Upcoming section contains, please create issues for each of these plans if we want to pursue them.

Upcoming

Unscheduled

• Create a script to pack the basic module and any given set of service-specific classes as one file. I still like the idea that a given API (e.g. Facebook) could be packed into a single file, and dropped into another project as a unit.

• Actually support OAuth

• Use a real, venerable test framework — maybe unittest

• Support Request/Response compression. Here's a great tutorial

• Get total coverage in the test suite, with the possible exception of actually sending a request across the wire

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

v3.0

• Unbreak the test suite
• Be consistently camelCase (Exception: the media-type converters in Content (e.g. application_json) should stay the same.)