~vcs-imports/pyrrd/trunk

« back to all changes in this revision

Viewing changes to TODO

  • Committer: duncan.mcgreggor
  • Date: 2011-06-24 19:11:26 UTC
  • Revision ID: duncan.mcgreggor-20110624191126-ap5cqny9cvx22auw
Removed files in an effort to decrease maintenance efforts. Source code will
now only be available on Launchpad.net (https://launchpad.net/pyrrd).

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
==========
2
 
Known Bugs
3
 
==========
4
 
 
5
 
* http://code.google.com/p/pyrrd/issues/list
6
 
 
7
 
====
8
 
TODO
9
 
====
10
 
 
11
 
Near Term
12
 
---------
13
 
 
14
 
* Move test code around (testing and admin/testRunner).
15
 
 
16
 
* Fix breaking tests.
17
 
 
18
 
* Add wiki examples for using info and fetch
19
 
 
20
 
* Add a wrapper for the Python RRDTool bindings
21
 
 
22
 
  - Since the doctests are mostly to show API functionality, we'll need to add
23
 
    unit tests for both backends (cli wrapper and bindings wrapper).
24
 
 
25
 
  - DONE - The python bindings should be fairly straight-forward to support,
26
 
    since we should just be able to split on the parameters that are currently
27
 
    calculated.
28
 
 
29
 
    From issue #5:
30
 
 
31
 
    On that last point, this is how PyRRD currently wraps the command line
32
 
    interface:
33
 
 
34
 
      * a private function concatenates a string of "rrdtool", the rrdtool
35
 
        command to execute, and then the list of arguments that need to be
36
 
        passed to the chosen rrdtool command
37
 
 
38
 
      * this string is then used in a call to subprocess.Popen.
39
 
 
40
 
    The list of arguments is built by functions whose primary job is to finagle
41
 
    arguements such that they can be passed to the private (and generalized)
42
 
    _cmd function. It is these functions that are used by the object oriented
43
 
    code.  The module that contains these functions is pyrrd.external and the
44
 
    work that is does needs to be adjusted for use by the bindings in
45
 
    pyrrd.bindings.
46
 
 
47
 
    In a twist of awkwardness (that needs to be refactored), these functions
48
 
    are called by the object wrapper after calling another utility function,
49
 
    prepareObject. preparObject does the final massaging of parameters suitable
50
 
    for consumption by the command line tool. If this workflow is preserved,
51
 
    then pyrrd.bindings will need a prepareObject function as well.
52
 
 
53
 
    The python bindings essentially have the same usage as the command line
54
 
    tool. As such, the rrdtool parameters that are currently prepared by PyRRD
55
 
    look to be almost usable as-is with the python bindings.  Some adjustments
56
 
    will have to be made, however. Currently, the parameters are assembled
57
 
    strings passed to Popen with shell=True. There's a good chance that we'd
58
 
    get very close to perfect suitability with the bindings if PyRRD changed to
59
 
    a list of parameters and called Popen with shell=False.
60
 
 
61
 
    Yikes! That last bit won't work: some parameters are quoted strings with
62
 
    spaces in them, and that needs to be supported.
63
 
 
64
 
    In addition to wrapping the bindings, the following adjustments will need
65
 
    to be made to pyrrd.
66
 
 
67
 
    So, in a nutshell, the plan is this:
68
 
 
69
 
      * DONE - write some proof of concept code that demonstrates the use of
70
 
        PyRRD with the python bindings for rrdtool
71
 
 
72
 
      * compare this with the current implementation, and generalize
73
 
        appropriately
74
 
 
75
 
      * refactor the current awkward parameter processing to be as
76
 
        straight-forward as possible
77
 
 
78
 
      * adjust individual method implementations as necessary, based on
79
 
        performance (bindings vs. external)
80
 
 
81
 
* Allow for users to supply their own fd to pyrrd.graph.
82
 
 
83
 
* DONE - Allow for users to decide which backend will be used on an
84
 
  instance-by-instance basis.
85
 
 
86
 
* Update all examples for recent dates like example4 has been updated.
87
 
 
88
 
* Stop using actual file writes and doctests for file tests; use unit tests
89
 
  (and StringIO) instead.
90
 
 
91
 
Future
92
 
------
93
 
 
94
 
* Add an RPN class.
95
 
 
96
 
* Add a DS collection class that has a get() method for getting a
97
 
  particular DS by name.
98
 
 
99
 
* Add support for atomic operations.