1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
==========
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.
|