Created project essentials
Created test suite framework
Bumped version to 0.0.2
Imported test data from PHP code for Detector implementation
Done with Detector implementation
Refactored Detector and bumped version to 0.0.3
Extended test suite framework for Client implementation
Multiple progress and revisions, bumped version to 0.0.4

1). completed pycurl-based Client implementation
2). added a new API-abstraction layer and combined it with the resource bundle
3). moved the development section of README.rst to docs/DEVELOPMENT.rst
4). added stubs for example projects
Completed requests-based Client implementation
Refactored Client and bumped version to 0.0.5
Working on WSGI middleware

    The existing interface specification of ``Detector`` and ``Interceptor``
    does yot yield a clean use case for WSGI middleware. The constructor of
    ``Detector`` (i.e. ``Detector.__init__()``) takes the ``environ`` (HTTP
    request) as an input parameter. For WSGI applications, however, the HTTP
    request is *not* available at the global scope, but only as an input to
    the application's ``__call__()`` method.

    This means either (i) the ``Detector`` object needs to be constructed
    within the WSGI middleware's ``__call__()`` method, or (ii) the
    specification of ``Detector.__init__()`` needs to be changed.

    For option (i), the WSGI middleware needs to have access to all 6 parameters
    required by``Detector.__init__()`` and this greatly violates the decoupling
    and encapsulation principles of OOP.

    For option (ii), the ``environ`` (HTTP request) need to be supplied to
    ``Detector.detect()`` instead of ``Detector.__init__()``. This will make a
    ``Detector`` object stateless with respect to the HTTP request.

    Starting from 0.0.6 at the ``develop`` branch, the implementation of
    ``Detector`` is based on the above-mentioned option (ii), and it breaks
    backward compatibility of ``Detector`` intentionally.
Done with Interceptor implementation
Refactored class interfaces, bumped version to 0.0.6

1). renamed ``Client.request()``->``Client.__call__()``:
    request is an ambiguous term in the context of SnapSearch.
    It may refer to (a) the incoming HTTP request from the robot,
    or (b) the outgoing HTTPS request to SnapSearch backend.

2). renamed ``Detector.detect()``->``Detector.__call__()``:
    for a stateless ``Detector`` (introduced since 0.0.5 and
    reasoned in Development Memo III, Issue 11), ``detect()`` is
    the only functional method, it is more Pythonic to make the
    entire object callable through the ``__call__()`` method.

3). renamed ``Interceptor.intercept()``->``Interceptor.__call__()``:
    same reason as 2).

4). renamed ``api.request.Request``->``api.environ.AnyEnviron``:
    same reason as 1).
Extended test suite for Interceptor implementation
Revisions to api abstraction layer
Done with WSGI/CGI Interceptor implementation