amps-python-client 5.3.4.1__zip → 5.3.4.3__zip

amps-python-client-5.3.4.1/PKG-INFO

@@ -1,112 +0,0 @@
-Metadata-Version: 2.1
-Name: amps-python-client
-Version: 5.3.4.1
-Summary: AMPS Python Client
-Home-page: https://crankuptheamps.com
-Maintainer: 60East Technologies, Incorporated
-Maintainer-email: support@crankuptheamps.com
-License: Commercial/Proprietary :: see LICENSE
-Platform: Linux
-Platform: Windows
-Classifier: License :: Other/Proprietary License
-Description-Content-Type: text/markdown
-License-File: LICENSE
-
-AMPS Python Client
-==================
-
-Introduction
-------------
-
-The AMPS Python Client is a Python extension module that makes it easy to connect to AMPS. This client builds upon the AMPS C++ Client and Python/C api to bring high performance AMPS connectivity to Python code.
-
-
-Prerequisites
--------------
-
-To use the AMPS Python Client, you must have the following software installed and configured on your system:
-
-* Python 2.7 or Python 3.5 and above.
-* Python distutils. Most python installations build and include this package by default, but you may run into issues building this extension module if distutils is not functioning properly on your system.
-  Python distutils may be packaged in a standalone package named 'python-distutils', or included in 'python-devel.x86_64'. You can also run the setup script available [here](http://peak.telecommunity.com/dist/ez_setup.py).
-* C++ compiler. gcc 4.4 or greater on Linux, or a verion of Visual Studio with Mainstream Support from Microsoft (please
-  refer to Microsoft product lifecycle policies) on Windows. Note that this must be the same compiler used to build your
-  python distribution, else python distutils may be unable to invoke your compiler.
-
-
-Fedora prerequisites:
-1. dnf install redhat-rpm-config
-2. dnf install python-devel  # for use with Python2
-3. dnf install python3-devel # for use with Python3
-4. dnf install gcc-c++
-
-Building From a Git Clone
--------------------------
-
-If you obtained this client by a git clone of the 60East amps-client-python repository, you also need to fetch the correct version of the 
-AMPS C++ client submodule. To do this, issue a git submodule command to initialize and update the src/cpp submodule. One easy
-way to do this is by issuing the command:
-
-    git submodule update --init
-
-which will initialize and update the submodule in one step. Note that working with submodules in git requires extra care. Visit
-[this chapter](http://git-scm.com/book/en/Git-Tools-Submodules) to learn more about git submodules.
-
-Build
------
-
-This client is distributed as source code and must be compiled before it is used. The build process emits a shared library
-(or DLL on Windows) that can be imported into your python application.
-
-### To build on Linux:
-
-1. Run `python setup.py build` from the AMPS Python Client directory to build the client.
-
-   This script uses Python distutils to build the client library. Python distutils provides many additional options for installing the built library into your Python distribution, or
-   otherwise controlling the output of the build process. Run `python setup.py --help` to view command help.
-
-2. Check under the `build` directory for `AMPS.so` -- this is the Python extension module. Ensure this library's directory is in your PYTHONPATH.
-
-3. To test, run `python -c "import AMPS"`.  If any errors occur importing the AMPS module, validate that the module built properly, and that the containing directory is in your PYTHONPATH.
-
-### To build on Windows:
-
-1. Use a Visual Studio Command Prompt to create a command prompt where the necessary Visual Studio environment variables are set for command line builds.
-
-2. Add the Python directory (the location of the python.exe interpreter) to your path.
-   *Note:* The platform of your python installation must match the target platform for this python module. If you want to
-   build a 64-bit module, you must set your PATH to a 64-bit Python installation; for a 32-bit module, you must set it to
-   a 32-bit installation. If you'd like to build both, you must do so separately, once with each Python installation.
-3. Run `python setup.py build` fom the AMPS Python Client directory to build the client module. Use the `-p win32` option to build a 32-bit client module.
-4. Check under the `build` directory for `AMPS.pyd` -- this is the Python extension module. Ensure this library's directory is in your PYTHONPATH.
-5. To test, run `python -c "import AMPS"`. If any errors occur importing the AMPS module, validate that the module built properly, and that the containing directory is in your PYTHONPATH.
-
-Installing the Python Binary Wheel
-----------------------------------
-
-60East also provides Linux-x86-64 and Windows 64-bit binary wheels built with Python 2.7 and for Python 3.x.
-These wheel files are provided on the 60East website.
-
-If your system is not Linux-x86-64, or you are not using Python 2.6, you can generate your own egg by running 'python setup.py bdist_wheel'.
-
-## Installing:
-
-1. Download the wheel file from the 60East client release page.
-
-2. run 'python -m pip install *.whl'.
-
-Troubleshooting Build Problems
-------------------------------
-
-Symptom: Python.h not found
-
-Resolution: Update or install python distutils. See the entry on python distutils in the prequisites section for information on installing this package.
-
-
-For More Information
---------------------
-
-The developer's guide and generated reference documentation for this client are available under the doc/ directory.
-
-
-

amps-python-client-5.3.4.1/docs/command-reference/html/.buildinfo

@@ -1,4 +0,0 @@
-# Sphinx build info version 1
-# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
-config: 951caf5bd819336a64039cd238b22ebf
-tags: 645f666f9bcd5a90fca523b33c5a78b7

amps-python-client-5.3.4.1/docs/command-reference/html/_sources/chapters/ack-messages.rst.txt

@@ -1,32 +0,0 @@
-.. _#command-guide-ack-messages:
-
-Ack Messages
-=================
-
-AMPS provides information to the application and
-AMPS client about the status of commands using
-acknowledgement, or ``ack``, messages.
-
-A command to AMPS must explicitly request
-acknowledgement to receive a response from AMPS.
-By default, the AMPS client libraries request
-acknowledgements as needed to detect failures:
-see the *AMPS User Guide* chapter on
-acknowledgements and the *Developer Guide*
-for each client language for details.
-
-In some cases, an application may want additional
-information about the state of a command, and may
-request an ``ack`` explicitly.  For example,
-an application may want to know how many records
-would be returned by a particular query. In that
-case, a common technique is to request a ``stats``
-(statistics) ``ack``, while setting the number
-of data messages to be returned to ``0`` (using
-the ``top_n=0`` option).
-
-This section describes the ``ack`` messages
-returned by AMPS.
-
-.. include:: ./ack-messages/ack.inc
-

amps-python-client-5.3.4.1/docs/command-reference/html/_sources/chapters/content-messages.rst.txt

@@ -1,27 +0,0 @@
-.. _#command-guide-content-response:
-
-Content Messages
-====================
-
-AMPS provides three types of message that contain message content:
-
--  ``publish`` messages return data from a topic as it is published, in
-   order, whether the data is being published live, or is the result of
-   a replay
-
--  ``sow`` messages return data from a SOW query. These messages return
-   the state of messages that are current as of the time for the query.
-   By default, the messages are returned without regard to the order in
-   which the messages were published. A query can specify the order of
-   the returned messages based on the data within the message by
-   including the OrderBy header on the SOW query.
-
--  ``oof`` messages indicate that a content message no longer matches a
-   subscription. These messages are sent to a client in order.
-
-.. include:: ./content-messages/content_publish.inc
-
-.. include:: ./content-messages-sow.inc
-
-.. include:: ./content-messages/oof.inc
-

amps-python-client-5.3.4.1/docs/command-reference/html/_sources/chapters/intro.rst.txt

@@ -1,43 +0,0 @@
-.. _#command-guide-intro:
-
-Introduction
-===========================
-
-This guide includes a listing of all AMPS commands as well as the
-required and optional parameters. AMPS supports a consistent set of
-commands and options regardless of the protocol used to communicate with
-AMPS. This guide covers the semantics of the commands and options, but
-does not cover how those commands and options are represented in any
-particular protocol. Each protocol uses a different concrete format for
-messages, and that format is specific to the protocol.
-
-To use a command from your application, set the properties of the
-Command object as shown in this guide, the use the execute function to
-send the command. The AMPS client is responsible for interpreting the
-command and formatting the message to AMPS in the proper format for the
-specific protocol the client is using.
-
-This guide lists the available options and their usage.
-When using the AMPS client libraries (either with the
-named convenience methods or with the ``Command`` interface),
-your application only needs to specify a subset of
-options. The AMPS client itself will handle
-formatting the command, adding options necessary for
-submitting the command (such as requesting a response
-indicating if a subscription succeeded, and so forth).
-
-The Developer Guide for each language provides a
-cookbook for common commands to AMPS, and indicates
-which fields and options to set for those commands.
-
-.. tip::
-
-  The AMPS client libraries handle many of the details
-  for an application, such as handling heartbeating,
-  requesting acknowledgement on commands, and so on.
-
-  The Developer Guides for the AMPS client libraries include
-  a reference that lists the fields and options to
-  set to produce a specific result.
-
-

amps-python-client-5.3.4.1/docs/command-reference/html/_sources/chapters/logon.rst.txt

@@ -1,231 +0,0 @@
-.. _#command-guide-logon:
-
-Logging on to AMPS
-==================================
-
-To help identify clients and users, it is recommended that clients send
-a ``logon`` command to the AMPS engine and specify a client name. By
-default, AMPS requires a ``logon`` command as the first command
-when a client connects. 
-
-AMPS only allows a single ``logon`` command for each connection. The
-``logon`` command must be the first command sent over a new connection.
-Otherwise, AMPS performs an implicit ``logon``, causing any other
-``logon`` commands for the connection to be rejected.
-
-In AMPS configurations where authentication is enabled, all connecting
-clients must issue a ``logon`` message with the ``username`` and
-``password`` credentials specified in the command. Attempts to logon to
-an AMPS instance that do not contain the information required will be
-rejected and prohibited from issuing further commands until a successful
-``logon`` has been placed.
-
-If an AMPS client is connected to an instance that has a transaction log
-enabled, the ``ClientName`` specified *must* be unique for the instance.
-Only one client with the same name is allowed to connect to the instance at a
-given time. If an application  logs on with the same ``ClientName`` and
-authenticated user name as an existing connection, AMPS assumes that the new
-logon is a reconnection from the existing connection and disconnects the
-existing connection. If an application logs on with the same ``ClientName`` as
-an existing connection but a different authenticated user name, the new logon
-will fail.
-
-It is recommended that all ``logon`` commands request that a
-``processed`` acknowledgment message be requested in the ``AckType``
-header of the ``logon`` message. This will allow AMPS to communicate the
-result of the ``logon`` command to the client, allowing the client to
-determine how to best proceed.
-
-.. note::
-
-  The ``websocket`` protocol uses a different
-  mechanism that contains the same information
-  rather than sending a ``logon`` command.
-
-Header Fields
--------------
-
-The following table
-contains the header fields available to a ``logon`` command.
-
-.. _#command-logon-headers:
-
-.. list-table:: 
-     :header-rows: 1
-
-     * - **Field**
-
-       - **Description**
-
-     * - ``Command``
-
-       - The command to be executed. Value: ``logon``.
-         
-
-     * - ``ClientName``
-         
-
-       - A string identifier used to give a client a
-         unique id. AMPS does not limit the character set
-         used in this name. However, the specific
-         protocol may have character set limitations.
-         60East recommends that the client name is
-         meaningful, short, human readable, and avoids
-         using control characters, newline characters, or
-         square brackets.
-
-     * - ``AckType``
-         
-
-       - Acknowledgment type for the given command. Value
-         is a comma separated list of one or more of the
-         following: ``none``, ``received`` or
-         ``processed`` .
-
-     * - ``MessageType``
-         
-
-       - The message type for the connection. Required
-         if the Transport accepts any message type.
-
-     * - ``UserId``
-         
-
-       - The username passed into the AMPS authentication
-         and entitlement module.
-
-     * - ``Password``
-         
-
-       - The password passed into the AMPS authentication
-         and entitlement module.
-
-     * - ``CorrelationId``
-         
-
-       - A user-provided string that will be included in
-         the log message recording this logon, and in the
-         information provided for the connection in the
-         administration interface. AMPS does not
-         interpret this string or use the string for any
-         other purpose. If this header is not present,
-         AMPS does not store a value for the
-         ``CorrelationId`` for this connection. The
-         contents of this header must consist of
-         characters that are legal in Base64 encoding.
-
-     * - ``Version``
-         
-
-       - The client library version (typical includes
-         the language and build number) of the client
-         making the connection. This version number
-         is logged for the connection, but does not
-         otherwise affect the connection.
-
-
-*Header fields supported by logon*
-
-Returns
--------
-
-A ``logon`` message specifying an ``AckType`` of ``received`` or
-``processed`` will receive an ``ack`` message to acknowledge the message
-receipt. If a client requests an acknowledgment message, the header will
-also contain the ``ClientName`` which was part of the original ``logon``
-message.
-
-When requested, the ``logon`` command will result in a ``processed``
-acknowledgment message. This returned acknowledgment is used in
-determining if a client was successfully authenticated against a server
-which has an authentication module enabled.
-
-The following table
-contains the acknowledgment messages that can be returned by a ``logon`` command.
-
-.. _#command-logon-acks:
-
-.. list-table:: 
-     :header-rows: 1
-
-     * - **Acknowledgment**
-
-       - **Description**
-
-     * - ``none``
-         
-
-       - No ``ack`` message is returned. This is the
-         default behavior.
-
-     * - ``completed``
-
-       - Not supported at this time.
-
-     * - ``persisted``
-
-       - Not supported at this time.
-
-     * - ``processed``
-
-       - AMPS has processed the ``logon`` message.
-
-     * - ``received``
-
-       - The ``logon`` command has been received.
-
-     * - ``stats``
-
-       - Not supported at this time.
-
-
-*Acknowledgment messages supported by logon*
-
-
-Options Field
-^^^^^^^^^^^^^^
-
-The following table
-contains a list of the ``Options`` available and their definitions when used in the AMPS 
-``logon`` command.
-
-
-.. _#command-logon-options:
-
-
-.. list-table:: 
-     :header-rows: 1
-
-     * - **Option**
-
-       - **Description**
-
-     * - ``none``
-
-       - This is the default ``Options`` type.
-
-     * - ``ack_conflation``
-         
-
-       - When provided, the interval at which AMPS
-         conflates ``persisted`` acknowledgement messages
-         for publishes sent on this connection.
-         
-         AMPS conflates ``persisted`` acknowledgement
-         messages when a transaction log is configured
-         for the instance.
-         
-         Defaults to ``1s`` if no option is provided.
-
-     * - ``pretty``
-         
-
-       - When provided and set to ``true``, AMPS returns
-         a formatted representation of the contents of
-         the built-in binary message types rather than
-         the original data.
-
-
-*Options supported by logon*
-
-