An interesting starting point?

[gianarb]

Hi! Thanks for your job at InfluxDB, it is a nice tool!

We use it in ours applications written in PHP.
I'm here to underline ours influxdb-php-sdk and to submit it to influxdb community.
This SDK now support UDP and TPC (Guzzle) protocols but exist standard interface to write your implementation. It's fully tested and very simple to use it and extendable.

1. Use composer to manage dependency

composer require corley/influxdb-sdk

1. Create your client

$options = new Options();
$adapter = new UdpAdapter($options);

$client = new Client();
$client->setAdapter($adapter);

1. Mark your points

$client->mark("app.search", [
    "key" => "this is my search"
]);

It's very integrable with dependency injection containers like SymfonyDiC or any other framework.

See README.md

What do you think about it?

[fntlnz]

👍

[pauldix]

Looks good. Sometime in the next few months we're going to try to publish some guidelines about base libraries and what their API should look like. Currently there's no consistency across languages so we'd like to shoot for that. First, we have to get 0.9.0 out the door.

[skynet]

Well, too bad, a great community around corley/influxdb-php-sdk and you guys chose to include another repo, which is poorly maintained. Start to have doubts about management at InfluxDB and the always breaking InfluxDB itself! @toddboom @pauldix - what say you?

[thecodeassassin]

We do not poorly maintain this library @skynet. This library is actively being maintained and updated. You can always choose to use another repo. At least contribute yourself if you wish to improve this or any other library, we would lile to make things better for the InfluxDB community.

[skynet]

I was your best supporter when you started this but recently I don't see any development here. Since InfluxDB is changing so often I guess you should be the first to adapt this library to its API changes. But lately I found more support in the other php client. So, I am questioning how InfluxDB chose to make your code official and not corley/influxdb-php-sdk. I have applications in production that break due to InfluxDB changing and changing, they seem not to make their mind easily, and there's little explanation on why they make breaking changes. I just hope that one day InfluxDB will become stable. So there it goes - my conclusion is that something is wrong with the management at InfluxDB!

And yes, I am contributing, by trying every new release and reporting back the problems.

[skynet]

Ok, or maybe I am just over-reacting. InfluxDB has a huge community around it, and great support. It's just that the php client is definitely lagging behind.

[skynet]

@thecodeassassin - you don't have a community yet. Just placing this repo next to InfluxDB itself didn't make it an instant winner, against other repos. Somehow it did, but not for community benefit.

[fntlnz]

👍 for @skynet - moreover I can't see the reason why they started writing another client since the guys at corley clearly proposed them self to do so.
The first commit here is on 16th June, pretty new compared to corley's one.

[thecodeassassin]

@fntlnz @skynet

Let me explain a few things:

First off it's hard to keep up with the developments of InfluxDB because their changes break our library. We need to properly test any changes before we ship the library because we don't want people to use a broken library. More than often these changes made by InfluxDB require a lot of testing and/or opening issues with InfluxDB itself, and this takes time.

So why did we write this client?
The reason we wrote this client is because of the reasons outlined by @pauldix and that was to make a library that is more in line with how the other libraries are written. Also it was a personal project for me and @danibrutal because we were using the library from crodas (not corleys, as we didn't even know about corley's library at the time of inception) and the code quality was not up to our standards. It was also lacking active development.

It also happens a lot that some changes are in fact not reflected in any of the changelogs but still break the library. This requires us to do end-to-end testing; which might be reduced by implementing functional tests but on the whole it still takes a lot of time and effort.

We are actively reaching out to the community to help us with this struggle. We don't consider ourselves a "winner" because the guys at InfluxDB chose our library, we just want to make a good and functional library for a project that is very; very volatile. You're talking about community benefit right? Well we spend countless hours writing extensive documentation and spend nights looking through influxdb code to make sure that our library doesn't break. Some changes are not listed as breaking changes (such as influxdata/influxdb#276) but still break our library. Other complications include incorrect/confusing documentation and changes that are not listed anywhere.

The guys at corley created a nice library for InfluxDB, they have a vastly different approach and thus cannot properly be compared. But we are not abandoning this library. The reasons of choosing this library over the one from corley should be a matter of choice, i already stated the reason why InfluxDB supported this library. You can make up your own mind on which one you want to use.

[skynet]

Fair enough. And very good points. Please accept my apologies.

Frustration comes from the fact that we have applications that break all the time due to InfluxDB changes.

I wish someone from InfluxDB had a say on this. @toddboom @pauldix