CloudServices/Notifications/Server

The following page contains a list of open discussion points about the Mozilla Push Notifications server.

Hide Broker Behind HTTP REST API

Pros

• Can pool multiple connections into one connection (using multiple channels on that one connection)
• Simpler for developers to build their own client (just do long-lived HTTP requests)
• Better security by preventing direct access to broker (if broker has a security hole, we would need to wait for a fix)
• Allows us to abstract away how messages are routed
• Allows us to support idea #7 by returning a 302 directing client to the new POST Office

Cons

• Extra server overhead

Enforce Exclusive Queues

Pros

• Easy to do with AMQP
• Extra security: can tell if someone else is "snooping" on your queue and take action (create a new one, forward all messages to new queue, delete old queue)

Cons

• Can't "share" single queue amongst multiple clients (not sure if we even want this -- does it even make sense?)

Persistent POST Office Connections

Pros

• Makes it easier for us to detect a DoS attack? (Apple uses this approach with APNS)
• Allow web apps to send bulk transfer of notifications (very useful for bulk senders like GMail)

Cons

• Makes it more complicated for providers as it requires they have a pool of persistent connections with which to send notifications
• Adds complexity to POST Office so we can support it?

Implement TTLs for Queues (and Messages)

Pros

• Easy to do with RabbitMQ extensions (see http://www.rabbitmq.com/extensions.html#queue-ttl and http://www.rabbitmq.com/extensions.html#queue-leases)
• Prevents server from being flooded with old messages that will never be read

Cons

• Could this be annoying for users? Probably not so long as we have a long enough TTL and make it clear to users it's enforced.

Alert Providers When Subscription Cancelled

Pros

• Providers only send notifications to "active" subscriptions (saves resources)

Cons

• To return error message from POST Office would be time consuming and would probably make the service incapable of large spikes in traffic (so we shouldn't do this)
• To return an error message asynchronously would require providers build a separate service for accepting cancellation messages. Another option is to have clients send a cancellation message, but this really should be done by the Client Agent to maintain users' anonymity (or should it?)

Send ACK to Provider When Notification Received

Pros

• Can support messages for which delivery must be assured

Cons

• Requires we build an entire messaging system that goes the other way? OR we could just reuse the current framework and have providers subscribe as a client. OR (even better) we could just spec a special notification type that allows the client to confirm the receipt of a notification (i.e. include a URL client can send ACK to).

Provide Mechanism to Move Client to a Different POST Office

Pros

• Allows us to re-balance our servers
• Gives users the power to move from Mozilla to their own server

Cons

• Could have security implications? (if attacker took control of Mozilla's servers and moved all its users to another notification server, for example)