search

picar / pyrrd

Automatically exported from code.google.com/p/pyrrd
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

Wrapping python-rrdtool #5

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
New feature. 
Crate wrapper for python-rrdtool, so it can be used as backend with PyRRD.
The external backend creates on overhead, by calling rrdtool through shell,
which is noticeable when a script makes many calls to PyRRD.

Original issue reported on code.google.com by mml...@gmail.com on 18 Feb 2009 at 10:54

GoogleCodeExporter commented 9 years ago 
Here are some notes I've taken when thinking about implementing this feature:

  * Since the doctests are mostly to show API functionality, we'll need to add
    unit tests for both backends (cli wrapper and bindings wrapper).

  * 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.

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 change 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.

In addition to wrapping the bindings, the following adjustments will need to be 
made to pyrrd.

So, in a nutshell, the plan is this:
 * 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)

Original comment by duncan.m...@gmail.com on 29 Mar 2009 at 7:16

GoogleCodeExporter commented 9 years ago 
There is now a first draft of this in subversion (trunk). If you're tracking 
this
project's code on Launchpad.net, there is a dedicated branch for it there:
lp:~oubiwann/pyrrd/bidings-integrataion.

Since this needs to be tested in multiple environments, I will not be bundling 
this
code into a release until we've had folks testing it and providing feedback, so 
the
rest is up to the you guys... :-)

Original comment by duncan.m...@gmail.com on 30 Mar 2009 at 7:38

GoogleCodeExporter commented 9 years ago 
This was committed back  in March. I haven't heard back from folks, so I'm 
closing this as fixed. If there are any 
issues with the wrapper, just open a new ticket for them.

Original comment by duncan.m...@gmail.com on 2 Jul 2009 at 4:23

GoogleCodeExporter commented 9 years ago

Original comment by duncan.m...@gmail.com on 29 Oct 2009 at 8:40