Recent update on uniqush-pushTue 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
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.