dumpResponses

[stefanak-michal]

I was thinking about adding new method to AProtocol called dumpResponses. It will serve to dump all pending responses ready to be fetched. Now if you want to do that you have to call something like this:

iterator_to_array($protocol->getResponses(), false);

So with this new method it will be:

$protocol->dumpResponses();

Any thoughts?

[transistive]

Aren't you still fetching them and just doing nothing with it? Isn't reset more what you are looking for? Just off the top of my head I'm out right now.

Also I think the name dump can be confusing. Considering there are names like die and dump in the php space, that means print in reality.

If you want to introduce a blocking call I'd just call it 'wait'. Its clear and concise.

Sent from Proton Mail mobile

-------- Original Message -------- On 18 Oct 2023, 16:53, Michal Štefaňák wrote:

I was thinking about adding new method to AProtocol called dumpResponses. It will serve to dump all pending responses ready to be fetched. Now if you want to do that you have to call something like this:

iterator_to_array(

$

protocol

->

getResponses

(),

false

);

So with this new method it will be:

$

protocol

->

dumpResponses

();

Any thoughts?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[stefanak-michal]

Oh you are right, I forget I can call reset ..thanks

[transistive]

We can still explore this idea further, though, like implementing a wait, but it will require more complicated data structures to keep it manageable, such as wrapping all messages around a promise A+ structure.

I like where your mind is right now 😏

[stefanak-michal]

nevermind ..reset is not the way. Because reset also has response about success/failure. So it is just another response waiting in buffer ready to be fetched. I wanted discard everything in that buffer and don't care what was in it. It would be nice if reset do what I want and also discard the buffer. But no, you have to get stuff from buffer.

[transistive]

I thought RESET has priority, which is why RESET is also a signal that can be received by the client. RESET just resets the pipeline, no?

[stefanak-michal]

You are right, it resets the buffer but reset itself creates a new response in buffer which has to be consumed. I'm sorry, I'm little bit confused. It's been a while when I was looking into this.

[transistive]

We should double-check with internals, but depending on the use case, I'd say you can just send RESET without reading anything and hope for the best 😅

I'm having trouble finding an actual realistic scenario for this as in order to reuse it, you probably have to consume the response first. You're better off creating a new connection at that point.