Recent update on uniqush-push

As I mentioned in uniqush after Go 1, uniqushd is now renamed to uniqush-push. However, it is more than a renaming work. I will review some changes on uniqush-push in this blog post.

HTTP responds more information

Users communicated with uniqushd through HTTP. Whenever a request was received, uniqushd would reply an HTTP response containing only one line: id=xxxxx. It is the request ID which helps users check the status in log. There was no other information responds from uniqushd. Users have to check log to see if a push was successfully sent to the cloud.

uniqush-push now uses HTTP as communicating protocol as well, but provide more information inside the HTTP response. On adding push service provider or subscribing a service, it responds the service provider's ID or delivery point's ID respectively. On push, it responds Success! on, well..., success. On failure, it responds the reason. But there is one exception: on retry, which usually happens on some temporary failure, it only respond Retry and users have to check log to see if the message is successfully delivered.

Fixed a bug

Thank @M_Cainelli for his bug report.

Description of this bug: send subscribe command to uniqush-push several times with same delivery point under same subscriber, push a message to the subscriber, there will be multiple messages pushed to the delivery point.

This is because of the cache mechanism in front of database. On adding a delivery point to a subscriber in the cache, we forget to check if the delivery point is already under the subscriber. This will then cause the multiple time of delivery.

Future

Besides, we have re-arranged the namespace preparing the comming of uniqush-conn. I am busy on designing the protocol between uniqush-conn and client. Hopefully, we could release uniqush-conn on time.