[rrd-developers] new rrd tool php extension

[Benny Baumann]

Hi,

Am 14.05.2010 14:44, schrieb Miroslav Kubelík - seznam:
> On Thu, 13 May 2010 13:17:14 +0200, Benny Baumann <BenBE at geshi.org> wrote:
>   
>> Could you give a small overview on the current implemented feature set?
>> Which functions of rrdtool did you already implement with your extension
>> which the older (see thread by me) extension (non-OOP) didn't already  
>> have.
>>     
> Nothing special nowadays, graph, update and create are already supported.  
> Maybe other will be in a future, but I need to investigate if the are  
> really needed and if I get achieve good php OO interface.
>   
Well, I actually though of something some time ago, but implemented that
in "userspace" rather than adding this to the extension itself. The
source for it isn't published anywhere, but if you want to take a peak,
mail me OL and I'll drop a copy. Basically my OOP Wrapper supports
Creating RRDs and Updating them in quite a nice interface (IMHO), but I
couldn't get a nice one for graphing as I couldn't quite think of a nice
integration of RRAs/CDEFs and VDEFs for usage in formulas.
> I know only about extension which is in the php svn repository and this  
> one is mostly 1:1 wrapper for rrd functions. This type of wrappers isn't  
> acceptable for PECL nowadays I think.
>   
Well, there's not much OOP you can squeeze out of RRDTool only given its
API layer. And at least speaking for me: Having only a small wrapper
which can be tested properly is preferrable over a large one with only
little change to get all the cases. And that's also the reason why I
wrote my OOP wrapper in PHP and not as part of the extension.
> My primary goal for OO extension is to provide very simple "PHP way"  
> interface for manipulating with rrd, which I can archive only with  
> objects, setters (mutators) and exceptions. I don't plan to use non-OO BC  
> functionality nowadays. Extension uses internally same functions as the  
> current one in the rrd svn.
>
> I read some threads about your patches, but I don't find any code. Can you
> send some links to code?
>   
One version is attached on a post from 30th Sep 2009 and can be found at
https://lists.oetiker.ch/pipermail/rrd-developers/2009-September/003464.html

I'd have to look if there were any more recent patches, but IMHO that
should be the one.
>> I'd be glad if we could "join forces" on the PHP Extension to avoid
>> duplicate coding and having a uniform extension interface for RRDTool.
>> Most people having a RRD Extension for PHP are using the version I
>> posted here on the list or some ancient anchestor of it.
>>     
> Nowadays I don't plan to keep BC with old extension, because I don't like  
> current extension behavior which is very similar to command line usage.
>   
But well. If I'm not fully mistaken its this "command line usage" that
all the other wrappers for RRDtool (for Python and Perl) implement. and
thus as a basis should be supported for PHP too as it makes porting code
across languages alot easier.

Adding an OOP-style way to do things won't harm here as people can
freely choose which interface variant to choose. But if the command line
interface was missing people would be limited to things you can explain
with your OOP way - which might be not enough for some cases.
> My goal is simple OO interface for basic rrd stuff, I don't think that php
> extension users need fetch, tune, xport, dump...
>   
Well. Actually I use exactly those - and the implementation of
rrd_dump_cb_r was due to me asking for it.
> There can be two extensions, OO extension code is different from the  
> procedural
> one in many ways I think.
>   
Well, there could be, but given from the name people should be able to
tell them apart. So for the PECL OOP version I'd suggest php_rrd_oop in
contrast to the php_rrd used for the command line version.
>> But well, having an OOP interface sounds cool to me and I'd be glad to
>> integrate it.
>>     
> Try to see my repo at http://hg.mirin.cz/phprrd/, there were problems last
> days, but now it could by fine. If you integrate it, I can give you an
> access to pecl if I get one. Then you can move your code as primary one to  
> pecl.
>   
hmmm, sorry, no Mercurial here. CVS, SVN and Git yes; but no Mercurial
;( Will have to see if I can get it work through Git somehow.
> M. Kubelik
>   
Regards,
BenBE.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20100514/1a2749b3/attachment.pgp