Merged https://github.com/jakubkulhan/bunny/pull/147 earlier today into the 0.6 dev branch. You can test it out with composer require bunny/bunny:^0.6@dev. Looking forward to any feedback on it before releasing bunny/bunny 0.6 in a few months. With the following other changes:
Kinda forgot how much fun it was to write code stitching map tiles together, and also how easy it was. Currently at 82 lines of #PHP. Once finished it will be a new package, as the #golang has some massive glaring bug in it that took me 6 years to find. Sprinkling some threads and #AMQP over this once it's done. The home clusters fans will sing once more
Getting close to a full green #Bunny running fully on @reactphp. There is one #TLS/#SSL test left to resolve before this will become the base for 0.6.x. #php#rabbitmq#amqp
Is there any advantage at using AMQP for new projects ?
We are investigating for MQTT also, looks lighter and there are much more implementations available (especially for managed services), but not sure what limitations we may face.
Not in an IOT context but purely message exchange for asynchronous processing between various internal components. #dotnet#amqp#mqtt#iot#development#python#ruby#golang
I'm growing to really dislike a lot of the #w3c#standards.
Specifically the following aspects:
There's no way to gradually implement half of these. You have to start with 80% of a complete working implementation.
A lot of them are technical solutions in search of problems. As with design patterns: you usually don't know what your problem is well enough to formalize it until it's been done a few times, and there is a lack of that lived experience here.
Like I need 80% of #ActivityPub implemented before I can even effectively test it. The same is true with #JsonLD.
Compare with, say, #gopher, or #STOMP, #ODBC, or #AMQP. Or even patterns like #REST. Even at their most complex I can get started writing something for them with no issue whatsoever, and libraries already exist in most major languages.