~heckj/pyrrd/devtest

==========

Known Bugs

==========

* http://code.google.com/p/pyrrd/issues/list

====

TODO

====

Near Term

---------

* Move test code around (testing and admin/testRunner).

* Fix breaking tests.

* Add wiki examples for using info and fetch

* Add a wrapper for the Python RRDTool bindings

  - Since the doctests are mostly to show API functionality, we'll need to add

    unit tests for both backends (cli wrapper and bindings wrapper).

  - DONE - The python bindings should be fairly straight-forward to support,

    since we should just be able to split on the parameters that are currently

    calculated.

    From issue #5:

    On that last point, this is how PyRRD currently wraps the command line

    interface:

      * a private function concatenates a string of "rrdtool", the rrdtool

        command to execute, and then the list of arguments that need to be

        passed to the chosen rrdtool command

      * this string is then used in a call to subprocess.Popen.

    The list of arguments is built by functions whose primary job is to finagle

    arguements such that they can be passed to the private (and generalized)

    _cmd function. It is these functions that are used by the object oriented

    code.  The module that contains these functions is pyrrd.external and the

    work that is does needs to be adjusted for use by the bindings in

    pyrrd.bindings.

    In a twist of awkwardness (that needs to be refactored), these functions

    are called by the object wrapper after calling another utility function,

    prepareObject. preparObject does the final massaging of parameters suitable

    for consumption by the command line tool. If this workflow is preserved,

    then pyrrd.bindings will need a prepareObject function as well.

    The python bindings essentially have the same usage as the command line

    tool. As such, the rrdtool parameters that are currently prepared by PyRRD

    look to be almost usable as-is with the python bindings.  Some adjustments

    will have to be made, however. Currently, the parameters are assembled

    strings passed to Popen with shell=True. There's a good chance that we'd

    get very close to perfect suitability with the bindings if PyRRD changed to

    a list of parameters and called Popen with shell=False.

    Yikes! That last bit won't work: some parameters are quoted strings with

    spaces in them, and that needs to be supported.

    In addition to wrapping the bindings, the following adjustments will need

    to be made to pyrrd.

    So, in a nutshell, the plan is this:

      * DONE - write some proof of concept code that demonstrates the use of

        PyRRD with the python bindings for rrdtool

      * compare this with the current implementation, and generalize

        appropriately

      * refactor the current awkward parameter processing to be as

        straight-forward as possible

      * adjust individual method implementations as necessary, based on

        performance (bindings vs. external)

* Allow for users to supply their own fd to pyrrd.graph.

* DONE - Allow for users to decide which backend will be used on an

  instance-by-instance basis.

* Update all examples for recent dates like example4 has been updated.

* Stop using actual file writes and doctests for file tests; use unit tests

  (and StringIO) instead.

Future

------

* Add an RPN class.

* Add a DS collection class that has a get() method for getting a

  particular DS by name.

* Add support for atomic operations.