Can we take a step back and explain what's the goal of this PR? If php-enqueue/amqp-lib already exists, why it should be rolled into this client library and not continue being a separate thing?

@michaelklishin

The main reason of the PR is to make messaging easy to do and open new opportunities for our PHP ecosystem. I am welcome you to join the queue interop group. Let's build it together

1. AMQP itself is a specification, not implementation and it would be good to have it reflected in PHP language. As an author of a library which relies on messaging, I do not want to choose between amqplib and amqpext. I want it to work with both! It's like psr/log or psr7 but for messaging.
2. Right now there are two main AMQP clients in PHP world: this library and amqp ext and they are not compatible. They have completely different APIs. So people build solutions that work with the library or with the extension only. All they start to build their own clients. Such a waste of time and resources.
3. Right now everybody is busy building yet another AMQP client whether it's built on top of this library or not. If we are agreed on messaging standard we can do a step further and start building more advanced stuff on top of the standard. Instead of writing yet another client developers can play with enterprise patters. It is a lot more fun IMO.
4. I can create a library on top of the standard that provides a delaying strategy based on dead queues or on the delay plugin without the need to the coupling on an implementation (an example of level up). Everybody can install it using composer and just use it. Right now we have loads of articles explaining how to delay messages using 100500+ different amqp libraries.
5. I hope frameworks will be more interested in adopting MQ if they have the ability to rely on pure interfaces.
6. The amqp-interop makes it easier to use AMQP. You learn the interfaces once and you are ready to use any compatible library.
7. Besides, the PR is relatively small.

@makasim I understand the premise of shim libraries and sometimes they make sense. My question is not so much about why php-enqueue exists but rather why this code should reside in this library and not be a library of its own, or a part of php-enqueue. It's not uncommon to see both
approaches in the open source world:

• Individual libraries provide their implementations of a popular shim library (such as logging shims)
• Shim libraries accumulate a bunch of implementations for libraries

The former approach is common for really popular shims (SLF4J in the JVM ecosystem, for example). When a shim is not particularly ubiquitous, it provides implementations for all the underlying "implementation" libraries.

Is php-enqueue really so widely deployed that this client should provide an implementation and tie itself to php-enqueue (the shim code won't maintain itself)? It seems to be a pretty new project spearheaded by a single company (or few companies).

@michaelklishin The solution does not rely on any enqueue lib part and does not require it. It needs only amqp interop interfaces.

The queue and amqp interops were originally developed as part of enqueue project but we decided to move it to a separate org. So it is clear to everyone that it's two different projects.

This interop is similar to this lib https://github.com/rabbitmq/rabbitmq-jms-client and shares a lot as they both based on JMS

@makasim perhaps I should put this more bluntly (I don't mean to offend you personally or your efforts with php-enqueue).

Why should the maintainers of this library sign up for maintaining this code, which is specific to php-enqueue? They are already quite busy. Who will updated it when php-enqueue interfaces change? Who will maintain it if php-enqueue is abandoned next month because your priorities change? Why can't it be a separate library under the php-enqueue org?

@makasim JMS has been ubiquitous in the JVM community for over a decade. It makes sense for any messaging related project to proivde a JMS interface implementation to the extent possible, in fact, some only provide a JMS interface.

php-enqueue is not nearly as widely adopted. I suggest that any code related to php-enqueue incubate in that org for a couple of years and then perhaps libraries such as this one or pdezwart/php-amqp can consider maintaining their own respective shims.

Unless @nubeiro or @hairyhum feel enthusiastic about accepting this PR, I think it's not a wise move for php-amqplib to make at this time.

I would like to stress out that the solution I am proposing has no direct relation to php-eqnueue.

I've worked on this stuff for a year and I am going to continue, that's what I paid for. I can support.

Symfony (one of the biggest PHP frameworks) incorporates AMQP extension. If they decide to support AMQPlib they will have to copy past 90% of their code. If it is based on interop interfaces it will remain the same. We are working on a PR that does same things as theirs but based on the interop, so this library could be used too.

I am serious about this stuff and I am not going to leave it anytime soon.

Also, the interop interfaces are cool, really. I am going to come back with reworked examples.

I add final to classes, it would be easier to support them, fewer BC breaks and so on and we can still learn and adjust interfaces.

Added interop examples

@makasim you are trying to sell me on the wrong idea and ignore my actual concerns. As I said, shim libraries can be useful. Only really popular shim libraries are supported by individual "implementations" of their interface and your projects aren't quite there yet. You are trying to make this library carry/maintain/indirectly promote your projects without offering any benefit for the maintainers or the majority of users (who are not aware of your interop libraries).

Your projects are objectively immature, largely unknown (at least not yet), don't have any technical reasons to include their bits into libraries such as this one. Unless @nubeiro or @hairyhum really like the idea, I'd say please come back in a couple of years.

@nubeiro @hairyhum please chime in or I'm going to close this later this week.

@makasim please no more arguments about how "interop is cool, really" or I am locking this discussion. Our concern is: why should we include/maintain/support your shim libraries forever (since removing something is quite hard once you include it)? Do you have a reason that goes beyond "but wouldn't it be cool if we were all singing and dancing users of the same common API"?

We can go on our own indeed but it'll take much more time to spread and adapt it to PHP community. If you accept this we can go quicker and persuade other projects to join the group. That's our plan and have just started.

Why do you need it? Well, all my arguments are based on the idea of shared\common interfaces and their wide adoption.

I am not new to open source: I created Payum library which is quite popular (I've been supporting for 5 years) as well as other projects that I maintained or contributed too.

So I am going to support this. I'll do my best so this won't bother you at all.

@makasim is trying to get everyone on the same page. Like it happened with the PSR/LogInterface and PSR/CacheInterface. the newset PSR/Containerinterface. The point is that One can use the library it wants and if the library doesn't support what he needs he can then switch elsewhere without rewriting a ton of code.

@mvrhov you are beating a dead horse. See #500 (comment).

@nubeiro @hairyhum any comments, please?

I don't see any change to php-amqplib in this PR. It looks like an separate library, which can perfectly exist on it's own and depend on php-amqplib.