Don't see your question below? Email us!
No, we cannot guarantee that. There is varying latency from one client device to the next, so even if one device published before the another, we might received the second one first. It's also possible for our servers to process requests out of order if one request hits a server with less load than a subsequent request.
That said, we do guarantee the ordering once we have processed a message, and our timestamps are done on a microsecond basis, so even if you are processing thousands of requests per second, we can preserve that ordering. Furthermore, the latency variations within our own server are on the order of a millisecond or two, so messages received at a lower frequency will generally be processed in order. However, network latency can vary much more widely across devices and geography, often by tens of milliseconds.
In short, we make every possible effort to preserve ordering, but in networked applications, it's impossible to guarantee it.
No. You can have as many connections at once as your users require. This is partly a benefit of our architecture and partly that we don't want to discourage liberal use of subscriptions.
Long-polling is the only reliable, standards-based method for asynchronous messaging over HTTP. The alternatives are Flash (proprietary) and WebSockets, which is relatively new and doesn't always work as expected in some network environments and browsers. For most applications, long-polling will work fine, and we'll introduce the option to upgrade connections to WebSockets in a future release.
Yes, although we have not yet established a timeframe for this. We are very much driven by your requirements. If we get a lot of developers asking us to support WebSockets, we'll accelerate development on it. Please let us know.
The short answer is AWS, Redis, Node, and [Ruby][jruby]. That doesn't really tell you much about us or our values as engineers though, does it? Our CTO Dan Yoder wrote a blog post that dives into our architecture in more detail.
Our Objective-C Client is already in the works and will be coming soon.
Yes. You can already use APN with embedded Web apps (ala [PhoneGap][phonegap]) or Ruby or JavaScript mobile development tools (ala Titanium).
Yes. In JavaScript, assuming channel is a channel object:
channel.subscriptions(function(error,subscriptions) {
// subscriptions is a hash of subscription names to subscription objects
});
You can also detect when a subscriber disconnects.
That has been true in the past. We've introduced two ways to use APIs within Web apps securely. First, we use authorization tokens called capabilities, instead of one-size-fits all authentication tokens. You can read more about capabilities and even see an example of how you might use them.
Second, we've introduced an Identity API so that you no longer need to issue capabilities (or other security tokens) from a server. Instead, people just log into your application using our Identity API and use capabilities associated with their profile. Check out our tutorial to see this in action.
Yes! We want to make it fast and easy for you to build cool applications, so we will be rolling out many additional APIs. Please tell us what services you'd most like to see!
Do you support SPDY?
No, but we will. No timeframe has been established yet.
We are fully committed to your ownership of all your applications data. We will provide you your data at any time upon request. Later, we expect to automate that so that you can simply export all your data with a simple API request.
We also stick to open standards and open source software wherever possible so that your code is dependent on any proprietary technology from us or anyone else. Or own server code is based completely on widely support open source projcets, ranging from Node to Redis.
Finally, we are open sourcing our own stack as aggressively as we can and already offer limited licenses to firms that are concerned about being dependent on our code.
In short, we're doing everything we can to ensure that you are never "locked in" to our technolgoy or any one else's. Our goal is keep innovating so that you don't want to use another solutions.
