So then I must just say that it was made on purpose.

cause the fluid interface has its limits in such case IMHO:

considering this:

$stream->set_context_option(..)
       ->add_flag(...)
       ->set_blocking(...)
       ->set_notification_callback(...)   //Here ends the configuraton of the stream, now let's run it.
       ->open()                           
       ->write(...)
       ->can_be_read(...)                 //Here Three possibilities: the stream did not change (like on an APNS successfull push), no need to try to read it otherwise endless loop...
                                          //If the stream changed, need to read.
                                          //If an error occured, skip to next read to see if write still works.

Then the case is the following:
no answer  > continue
answer     > read it but need to closed the connection cause APNS closed it too
If failure > this can happen if the system call is interrupted by an incoming signal(as the php manual says),
             can always try to write again.
       

From the APNS apple site:

"You should also retain connections with APNs across multiple notifications. APNs may consider connections that are rapidly and repeatedly established and torn down as a denial-of-service attack. Upon error, APNs closes the connection on which the error occurred."

Then it is safer to keep the connection open and close it and reopen according to the "can_be_read" call.

As I said, it's hard to review something without an actual use case. The one you gave in your comment is fine, but only one small part of the bigger picture. I wasn't talking about the can_be_read() function at all. If you look at set_timeout(), it returns a boolean, whereas I as a user would expect it to work like the other set_* methods.

As a said note, boolean methods need to start with is_, not with can_ and not with has_.

I agree with Heinz on the seconds and micro senconds thing, I don't think it makes much sense to pass them in every function instead of just setting them as part of the fluid interface.
I can't see functions returning booleans anymore, everything seems to follow the fluid interface properly.
For giving my opinion on the function changed and how it's used, I would need to see an specific use case.

For what concerns changed(), it is just a wrapper of stream_select and it is called in the "is_readable", "is_writable" and "is_exception_thrown" methods.

Use case is then:

$stream->is_readable(1);
Again for APNS, this is useful in order to know the return code if any, and then close the stream cause it is closed on server side.

I already made an implementation of the read and write methods that REOPENS the stream if the handle is not a resource(e.g was closed)
in the coming StreamSocketClient class.

To go further with the fluid interface, I would submit the following possibility:

    -adding methods, part of the fluid interface which would indicate the StreamSocket what to to in case of answer 
     (something was read after a call on is_readable) like "public function close_on_answer/close_on_read{...return $this}"
    
    -coupling this with a observer pattern, like StreamChangeListerner interface.
    
    -adding methods such as listen_to_answer or equivalent (part of the fluid interface)which would indicate the class what to do after sending data on the stream
     by making the stream listen to himself and consequently act on events such as "write"
	 
    -The boolean returning methods would then be set to protected ("is_readable", "is_writable" and "is_exception_thrown").
     With addition of extra property for the parameters and setters.

In the end, the APNS class would listen to the stream to know the status of the push...

Hope I was clear...

Whatever you mean with a StreamChangeListener is way out of scope for this review. One small step after the other. The review is already big enough, no need to make it any bigger. KISS

While this is a valid use case, it does not use the fluid interface. This can easily be rewritten as:

$stream = new StreamSocketClient(..);
$status = $stream->set_context_options($options)
                 ->add_flag(...)
                 ->write($msg);

if ($status === FALSE)
{
    $this->errno = 123;
    $this->errmsg = "Error";
    return;
}

...

Named like in the php manual.

I can, it stands for microseconds :) It's kinda easy when you have timeout next to it...

I dont see the point in doing this, timeout can be kept the same for multiple call.

Agree with olivier here, specially if we make them part of the fluid interface

As you wish but this is made to stay close form the original API and
to make the user aware of the fact this concerns the context.

The original API is of no concern to our API. That's the whole point of making a wrapper, otherwise we could just skip it and use the low level code directly.

To harmonize I propose the following:

-renaming set_context_option(s) to set_option(s)

the flags are different from the curl class because
it only concerns integer values spend as string,
but is not a key/value association.

finding another name is a possibilitie

So, looking a bit deeper, you can drop the $wrapper parameter. AFAICS there can only be one wrapper at a time and you can detect it from the URL you are using.
The you can rename $option to $key and we have exactly the same interface as in the curl class

This sounds clear to me.

set_timeout_in_seconds sounds like you want a time out in seconds only by some way

I would go for set_seconds_timeout

same here then

set_microseconds_timeout for me...

Cause the array given to stream_select are transmitted by reference.
http://php.net/manual/en/function.stream-select.php

sure, that's why it needs to be stored in a variable. But why do you store it twice?

Right did not notice that...

The difference is that the handle is not exposed.
Then you could have done thing like
while($read = $stream->read(1024))
{

}

which works fine but will be dine again and again you simply write

$stream->read_all();

which returns the whole available data testing internally the feof.
this is a convenience but I think this is relevant for future use of the 
extending classes.

So read() is a special case of read_all()? Then why do a special read() in the first place and not do a read_all() by default?

Because at first the need was to read a special amount of bytes.
Then the need for read_all came, I don't think this is such a big issue
to offer many possibilities.

I think is good to keep both, imagine you want to check the first line of whatever you receive to decide if you want to process it or not, then you would do a read and if it's what you want, a read_all afterwards

So we make a read($length = 0) where length 0 means read all. No?

Seems to be a good alternative, I'll check the possibilities for next review