soygul/gcm

GCM (Google Cloud Messaging) - CCS (XMPP Cloud Connection Server) and HTTP implementation.

gcm's Issues

Use simplified error handling

if err := datastore.Get(c, key, record); err != nil {

Vendor deps and move the new home

We don't want to maintain an XMPP lib and GCM implementation ourselves so it's better to use something else (plain HTTPS with batching even).

Send() closes xmpp connection for all error types and not just for connection errors

Close connection and raise an event in case of "Connection Draining" message from CCS

Handle delivery receipts and message queues

"message_type":"receipt" as described here: https://developer.android.com/google/gcm/ccs.html#receipts

message_status sometimes received, sometimes not..

Hi,

Thanks for this great library.

I have issue, that sometimes i receive delivery status from device, and sometimes not. My request is:

fcmMsg := &ccs.OutMsg{
To: deviceID,
Priority: "high",
DeliveryReceiptRequested: true,
DelayWhileIdle: true,
Data: data,
}

data is map[string]string.

Any known issue about this?

XMPP lib cannot handle stanza error responses

When we get following in response to a message with broken stanza (as described here: https://developer.android.com/google/gcm/ccs.html#stanza):

<message id="3" type="error" to="[email protected]/ABC">
  <gcm xmlns="google:mobile:data">
     {"random": "text"}
  </gcm>
  <error code="400" type="modify">
    <bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
    <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">
      InvalidJson: JSON_PARSING_ERROR : Missing Required Field: message_id\n
    </text>
  </error>
</message>

The resulting output is:
&{XMLName:{Space:jabber:client Local:message} From: ID: To:[email protected]/... Type:error Subject: Body: Thread: Other:[ ]}

We should instead get our broken request:

  <gcm xmlns="google:mobile:data">
     {"random": "text"}
  </gcm>

and the error details back in Other:[] array.

Use specific error types

Use error types specific to a given error along with extra info fields (maybe not? and simply favor simplicity). Either way, return type should always be error in method signature as advised in Effective Go.

Separate CCS communication logic from queueing logic (which should be common for both HTTP & CCS)

dequeue tip: "message_type":"receipt" as described here: https://developer.android.com/google/gcm/ccs.html#receipts

Try and move all documentation in tests into error messages as tests should be self explanatory even with concise names

Move example code into it's own file and link from readme

docs: http://golang.org/pkg/testing/#pkg-examples

change type of OutMsg.Data to support nested data

map[string]string (https://github.com/soygul/gcm/blob/master/ccs/message.go#L26) seems to assume that Data is flat - to support a nested structure, it seems it must be map[string]interface{} (as Google's implementation at https://godoc.org/github.com/google/go-gcm#Data is)

Integrate godocs

gracefully handle connection closed errors

or just return errors.New("connection closed")

not handling them at all is also an option (as in tls.Conn function which never account for closed connection)

Doesn't receive messages from iOS client

I am trying to send message from the device to the server with no luck. I use the sample code with the Receive function.

What happens when incoming message has both MessageType/From fields empty? Review specs

Execute main example after compilation

As per Go testing docs (http://golang.org/pkg/testing/#hdr-Examples), test functions are compiled but not executed if they do not have concluding line that begins with Output: .... statement. We should add that to our main example file ccs/example_test.go.

Receive() should return the message for further processing

Hi,

Currently, the message ID is generated when the message is sent, and we have no way of getting it before it gets across the wire.

I want to track my message delivery status and need a way to match an ACK to a sent message. Storing the message ID when it is crafted would allow me to do just that.

I can develop it myself and make a PR if necessary.

Regards,

getMsgID should optionally generate sequential message ID with cluster prefix

We can use sequential numbers optionally, just as the Android client does (1, 2, 3..) in upstream messages.

Cluster ID (process ID) can be prefix like: a1, b1, a2...

Do not log sensitive data and use Println where appropriate rather than Printf everywhere