👍 LGTM

Could you update the docs with an example?

Is the ContainerManager really the right place for this? If I understand correctly, this has nothing to do specifically with containers, so maybe it should be in Docker?

Coding standards: we usually put a white line before and after structure blocks like fors and ifs, except before a block that begins another block. For example, the splitEvents method would look like this:

        // ...
        $currentString = '';

        for ($i = 0; $i < strlen($contents); $i++) {
            if ($contents{$i} == '{') {
                $numOfBrackets++;
            }

            if ($contents{$i} == '}') {
                $numOfBrackets--;
            }

            $currentString .= $contents{$i};

            if ($numOfBrackets == 0 ) {
                if (!empty($currentString)) {
                    $retVal[] = new Event(json_decode($currentString, true));
                }

                $currentString = '';
            }
        }
        // ...

Also, +1 for the documentation, and this will also needs tests :)

I moved it into ContainerManager because those are container events. Maybe some new EventMenager? Tell me where you want it and I'll correct it and add docs.

We are talking about http://docs.docker.com/reference/api/docker_remote_api_v1.18/#monitor-dockers-events, right?

Yes.

Then it can also report image events:

and Docker images will report:

    untag, delete

So yeah, maybe an EventManager would make sense, maybe something based on https://github.com/symfony/EventDispatcher so that we can easily register listeners to these events, what do you think?

At the moment it uses polling. If you want to dispatch events it should use streaming. It should open /events and asynchronously react to received data converting it to events.

I might be wrong (don't know guzzle so good) but it seems to require guzzle5 with its asynchronous capabilities.

Right, I guess both polling and streaming can have their place in docker-php.

In the end, because /events can report image events, it shouldn't be in ContainerManager, but there might not be a need for an EventManager right now (you're right about the streaming, and we're already talking about switching to egeloen/ivory-http-adapter which would bring in async + psr-7 compliance, so this part should wait) so maybe you can move it to Docker\Docker and that would be fine for now, what do you think?

Hey, I put it into new place. It's not a lot of code but when async is added it will more. I don't want to change api then.
And there is a unit test now.

Ok that's great, ready to merge once the coding style issues are fixed!

poke @ggodlewski, are you going to fix the CS issues? :)

Why was this closed without merge? Are these changes in the code or in another PR?

As you see there were some empty lines missing and instead of just putting them he spent more time on writing comments.
I have a life. I prefer to use and contribute to another project.

@ggodlewski Thank you for the info, sad to hear the PR failed just because of code-formatting.

@ggodlewski sorry that you feel this way, but code formatting is important. If you do not wish to respect the work of others by complying to simple rules, that is your right and I hope you find another project to use and contribute to that will suit your needs and philosophy.

In the meantime, I would just like to point that being sarcastic and/or ironic is not necessary, and implying that your time is more valuable than that of other people here is, simply put, rude.