House cleaning: README correction, HTTP status code 204, return $this, and returnbody

[christophermancini]

This PR is to address issues #11 (CLIENTS-85), #27, #72 (CLIENTS-87) and #80 (CLIENTS-52) for Riak 1.4.x client. These are fairly small changes to do a little bit of house cleaning on the issues list. I corrected the README by adding a missing 'new' keyword, added the ability to override the returnbody parameter on store, added $this to the return for addIndex to make it consistent with the docblock, and added support for the Riak 204 status code for PUTs.

[hazen]

:+1: `cept the tests fail, but that seems to be unrelated to your changes

[debo]

Accordingly to Travis tests are failing likely as a consequence of this PR https://github.com/basho/riak-php-client/pull/77

Not quite sure though why the build is still failing. The path it is trying to point at exists but it seems it can't be seen.

[christophermancini]

The Travis tests were failing long before I started working on this library. I just fixed them for the 2.x rewrite and they passed. I will try to fix the 1.4.x release to get it passing again.

[debo]

I know, they were failing because some of the changes I made to fix the issue were reverted at some point. As I pointed out back then it's important to provide a passing build to the users to build trust with them. Also as suggested in past for the version 2.x I highly recommend the adoption of PhpSpec if possible or at least PHPUnit

[christophermancini]

So, looks like I accidentally let 5.4 array syntax slip into the 1.4.x build via my editor's auto reformat... my bad. I will fix it, plus I am updating the travis.yml, hopefully get the builds going green again. For 2.x, I am using PHPUnit and am keeping unit tests separate from integration tests. At the moment, I have several unit tests written that all pass but I still have a ways to go. Currently working on buckets, objects and CRDTs but the core structure is in place (main Riak class, building node cluster, node selection, api layer with future extensibility, and command framework). Hoping to have an alpha release sometime early Q1.

Are you currently using Riak with PHP?

[debo]

Good to hear. I called those tests integration because that what the old ones where, as you can see they rely on a real connection rather than a mocked one. PHPUnit or PhpSpec it's just a matter of preference in the end and I do prefer the latter but I'm fine with PHPUnit; if you are accustomed to it don't change unless you are curious.

Not yet, I had some plans in past and that's why I started contributing to the library but eventually I've been dragged into other things and lost a bit of interest. I'm happy to help if needed though since I see now there is a roadmap.

[christophermancini]

Well, hopefully the current efforts can align with your free time and renew your interest in Riak! :)

W.r.t. PHPSpec - PHPUnit, I do have experience with PHPUnit and have never used PHPSpec but to be honest, I want to keep the barriers of entry for this library to be as low as possible and in my opinion, PHPUnit has the highest community adoption which makes it my choice.

It's also why we decided to not pursue Protocol Buffers at this time because there is not a mature / stable / easy to use PHP library for PB that does not depend on a 3rd party PHP extension.

[debo]

About the PB support I think that for whoever needs to use it, adding a 3rd party extension as part of the provisioning phase shouldn't be a problem. The real constraint should be benefits; if using PB with the PHP library doesn't really bring any specific improvement than it's fine to skip it for the time being or even forever. Depending by that the development strategies and milestone might obviously change.

Let's see how it goes, I'm still on holiday so I think I won't touch any code till next year ;)