Recent update on uniqush-push

Tue 08 May 2012 by Monnand

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.


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.