README.md in suj-pusher-0.2.0 vs README.md in suj-pusher-0.2.3
- old
+ new
@@ -2,15 +2,15 @@
This is a simple but enterprise level pusher server that can push notifications to iOS and Android devices using the APN and GCM push services respectively.
## Features
-- Support both APN and GCM push services with a simple unified API interface.
-- Keep persistent connections to APN following Apple recommendation.
-- Use redis pub/sub mechanism for real time push notifications. No polling.
+- EventMachine based for efficient use of resources.
+- Support both APN, GCM, WNS, and WPNS push services with a simple unified json API interface.
+- Keep persistent connections to APN following Apple's recommendations.
+- Uses the APN protocol version 2 for batched notifications.
- No need to set APN certificates or GCM api keys in configuration files or pusher startup. These are sent in a per request basis. This allows support for multiple APN certs and GCM api keys in a single Pusher instance.
-- EventMachine based to handle in the order of thousands of push requests per second.
## Installation
Via gems simply install the suj-pusher gem on your system:
@@ -111,19 +111,12 @@
"sound": "default"
}
Read the [official documentation](http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW1) for details on the *aps* hash format. Note that this hash must not exceed the 256 bytes or it will be rejected by the APN service.
-#### Sending one message to both APN and GCM
-
-Normally you would send messages to either Android or iOS indenpendently. But the pusher daemon can send the same message to devices on both networks as long as you follow the Apple restrictions. This is because Apple push messages are more limited than GCM.
-
-If your data hash is compatible with the APN standard as described above and you specify a APN cert, a GCM api_key, a list of apn_ids and a list of gcm_ids then the message will be delivered via push notification to all the devices in those lists. Apple will display the notifications using their own mechanisms and for Android you will receive the data hash in a Bundle object as usual. Is your responsibility to extract the data from that bundle and display/use it as you please.
-
-
-
#### Sending one message to WNS
+
message hash: {
wnstype: "type" ,
wnsrequeststatus: true,
wnsids: ["xxx"],
secret: "app-secret",
@@ -134,11 +127,10 @@
data: a string with de notifiaction to send, please use the xml templates provided by Microsoft(http://msdn.microsoft.com/en-us/library/windows/apps/hh779725.aspx) for each wnstype listed above.
secret and sid: App identification credentials provided by microsoft when registering a new application to use wns services.
wnsrequeststatus: boolean, if true, the response from wns server will have aditional information
wnsids: jsonArray of target devices.
-
#### Sending one message to WPNS
message hash: { wptype: "type",
wpids: ["xxx"],
secret: "unicId",
development: false,
@@ -148,12 +140,10 @@
wptype: ype of the notification to send, posible values are: "toast" or "badge", if this parameter is not present, a "raw" type notifications will be sent.
secret: a unic hash to identify a conection, internal use, each notification sent must have a diferent id
wpids: jsonArray of ids for target devices
data: notification data to send, please use de xsml template provided by Microsoft(http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202945(v=vs.105).aspx) for each wptype listed above
-
-
## Examples
A simple example using ruby code to send a push notification to iOS devices.
```ruby
@@ -179,14 +169,12 @@
redis = Redis.new({ host: "localhost", port: 6379})
# Push the message to the *suj_pusher_queue* in the redis server:
redis.lpush "pusher:suj_pusher_msgs", msg_json
-# Notify workers there is a new message
-redis.publish "pusher:suj_pusher_queue", "PUSH_MSG"
```
-First you must push your messages to the *suj_pusher_msgs* queue and then publish a *PUSH_MSG* to the *suj_pusher_queue*. The first is a simple queue that stores the messages and the second is a PUB/SUB queue that tells the push daemons that a new message is available. Also make sure to set the same namespace (e.g. pusher) to the queue names that you set on the pusher daemons.
+Once you push the JSON message to the *suj_pusher_msgs* queue the pusher workers will retrieve and process it.
## Issues
- We have no feedback mechanism. This is a fire and forget daemon that does not tell us if the message was sent or not.
- This daemon has no security at all. Anyone that can push to your redis server can use this daemon to spam your users. Make sure your redis server is only accessible to you and the pusher daemon.