• fixes a bug in some implementation where the timeout is not respected (last wait should check for left time)
• implements a polling interval to fetch messages
• implements methods to set and get a visibility timeout

Hi @makasim

I viewed queue-interop a few months ago but never had time to properly give some feedback when you started the project, sorry.

Having worked on PSR-11, I can give you a bit of advices if you ever want to push this on the PHP-FIG for a PSR. So here we go:

PHP 5 vs PHP 7:

I saw you discussed the issue here (#2). You decided to go for PHP 5 support a few month ago, but the tide has turned since then. Then newly passed PSR-15 is PHP 7+ only and upcoming PSR will be PHP 7+. So you should definitely target PHP 7 now.

Naming:

The interfaces are named PsrXxx. For instance PsrMessage. "Psr" does not add any value. On the other hand, you like the Interface suffix. I know many people feel it's wrong to have an Interface suffix (I'm part of those), but there has been a poll on the PHP-FIG mailing list 2 years ago and it was decided to go with the suffix.

So you should rename your interfaces this way:

• PsrMessage => MessageInterface

Immutability:

PSR-7 objects (RequestInterface and ResponseInterface) are immutable. This is a very nice property to have as it prevents a number of side-effect bugs. It could be useful to have that in Queue-interop also (so you could drop all the setters from Message and replace those with withXxx methods).

Scope:

This is a big one. I think your interfaces have way too many methods. You want to cover all the existing features of all queuing systems. Maybe you should rather target what all systems have in common (i.e. send and consume) rather than putting all possible features of all systems in your interface.

For instance:

PsrProducer::setDeliveryDelay seems highly suspicious to me. First of all, the "delivery delay" notion could belong to a message rather than to a producer. It can be nice for producers to have default values, but this is an implementation detail, it has nothing to do in an interface. Then, an interface with setters is usually a code smell (if you want to know why, see https://ocramius.github.io/extremely-defensive-php/)

I really don't have much time to look in depth at queue-interop, but if you can get some people interested on the PHP-FIG mailing list (I know, it's hard), I'm sure you could get a ton of feedback that would probably change quite radically the structure of your interfaces. I started this way with container-interop, and it's really a great learning opportunity when you have all those skilled people looking at your code. So give it another try and try to gather some more feeedback, it's worth it!

This is only a suggestion, concentrate all Exceptions into Exception folder.

Example can be viewed in https://github.com/joubertredrat/queue-interop/tree/master/src

Maybe related to #4

This PR adjusts the original PR since it stopped being updated after reviews.

For myself, I've taken the liberty and removed StringBodyOnlyTrait since it's debatable whether it should be part of queue-interop or not. I do think it can be safely discussed in another PR if needed.

Second, I've removed default value for $body argument, since from my point of view it hardly makes any sense to use empty messages.

ref #27

Fixes #27 Supersedes #28

@makasim this is a 2nd PR with:

• a fix into /src/MessageTrait (there was an $id property that was a copy-paste error. The right one is $messageId
• no blank line at the end of /src/MessageTrait.php
• a test for this trait
• a TestCase to test all the implementations of the trait

I've used the same logic as with Symfony test https://github.com/symfony/validator/blob/master/Tests/Constraints/AbstractComparisonValidatorTestCase.php#L260 about how to get an instance to test.

Would you consider a PR with Trait to implement common methods defined by Interfaces?

I've in mind this Interop\Queue\Message interface.

Almost all implementations define the same method bodies which makes a lot of code duplicate that could be cleaned up.

Hello, Thanks for the initiative.

I have a suggestion. Object creations depend on PsrContext, which looks like a technical leak. Also, it brings a strong dependency on the context.

This is the current interface:

$context->createProducer()->send(
    $context->createQueue('aQueue'), 
    $context->createMessage('aBody')
);

With this interface, if I want to write a service pushing a message, it would either depend on:

• PsrContext, which is technical, and more than what I need (I don't want to consume the message there),
• or PsrProducer, plus handwritten QueueFactory and MessageFactory to hide the context.

What about having PsrMessage and PsrQueue as plain PHP objects ?

$context->createProducer()->send(
    new PsrQueue('aQueue'), 
    new PsrMessage('aBody')
);

Typically, I would let a dependency injection container manage PsrProducer instantiation. Then, my business class would just depend on the producer to send messages.

The producer being provided by the context has all necessary data to decorate the message and queue with technical information, without the end developer having to specify it.

This is in my opinion more DX. It would also reduce the PsrContext interface responsibility to PsrConsumer and PsrProducer creation.

For example:

\Interop\Queue\PsrContext -> \Interop\Queue\Context
\Interop\Queue\PsrQueue -> \Interop\Queue\Queue

\Interop\Queue\InvalidMessageException -> \Interop\Queue\Exception\InvalidMessageException

Is this effort still maintained? It appears to have no stable releases, just alphas, but Packagist reports a whole crapload of dependent packages and millions of installs. I'm not sure what to make of that. The most recent alpha tag also doesn't list PHP 8 compatibility, but master does.

Context: I am investigating possible queue solutions for TYPO3 and this is one I am considering. But if it's not actively maintained and PHP 8.1-friendly then it's not really an option for us.

The Problem

Not sure what the Git workflow used here is, but develop, which usually represents the latest unstable version, should probably not be behind master, which usually represents the latest stable.

Further more, for the reasons mentioned above, the masterbranch should not be the main branch of the repository.

Suggested Solution

1. Merge master into develop
2. Direct features/bugfixes to develop from that point onward.
3. Make develop the main branch of the repository.

Why message body is of type string https://github.com/queue-interop/queue-interop/blob/master/src/Message.php#L19? How can I send objects inside of message body? I need to double encode it? It is weird.

Java specification definitily says that body can be an object, a stream and so on https://docs.oracle.com/javaee/7/api/javax/jms/Message.html