> Microsoft's Push Notification Service (WNS) is a HTTP-based, which is awesome. Apple introduce a TCP-based approach to push notifications that basically requires you to write a dedicated sever (again, somehow, Apple didn't specify how to do) to send your push notifications through their APNS. No one rolls their own APNS server because it's too hard and there's Urban Airship.
This is ostensibly a professional engineer, and this position drives me bonkers ("not HTTP, too hard")!
Apple provided protocol documentation and a very, very simple TCP+SSL protocol. Rolling your own client should be a matter of a day or two of work, at the absolute maximum.
The fact that people are frightened of TCP and a simple binary protocol is a mind-boggling indictment of the ineptitude and inexperience of the engineers that have been placed in a position of responsibility.
I dealt with a server team recently that refused to consider a push-based feature because it would "cost too much to send that many pushes through Urban Airship". Implementing their own local client for the protocol never occurred to them, and our doing so for them dismissed out of hand ("too complicated").
I'm aware of Apple's sample code, I attended the WWDC talk on integrating Push Notifications. I'm just not aware of many Ruby developers interested in taking Apple's C example and implementing it in Ruby.
HTTP POST is simpler for the developer. TCP is better for Apple. Apple has the resources to scale, so "TCP is faster" isn't really an excuse, in my ostensibly professional opinion.
Apple has the resources to scale, so "TCP is faster" isn't really an excuse
Really? HTTP is just sending lines of text over TCP- what's so hard about a binary format instead? In many ways it's easier. You shouldn't need an excuse to remove unnecessary layers of translation.
> For a hobby developer or small business where time is precious, using built-in HTTP libraries is far easier and faster ... Sorry, but you're not going to convince me that rolling your own implementation of Apple's APNS is better than an HTTP-based APNS would have been.
Something is rotten in the state of Denmark; if this can be done in 20 lines of Python (see comment above), then why do so many ostensibly capable engineers find it so difficult?
In which case the failure to communicate is mutual; In OP, I said:
... this position drives me bonkers ("not HTTP, too hard")!
As professional engineers, it's my hope that opening up a persistent TCP socket and sending a small, stateless binary message should be easier, faster to implement, and better performing than marshaling everything into HTTP (for no other reason than HTTP is more familiar to you!).
If that's not the case, then I would strongly recommend that any engineers that are uncomfortable with this simple task should review UNIX Network Programming Vol 1, and Network Security with OpenSSL, rather than complain that an HTTP interface isn't available.
At the very least, such a study would provide a necessary understanding of what HTTP is doing. With that in place, opening up a connection to APNS should be a walk in the park.
But what is the actual advantage? Its all very well saying that it's easy to implement Apple's solution, but HTTP is simpler. What makes it worth having to spend a day or two on a custom solution?
Efficient high throughput performance. That's why Apple went with the protocol they did in the first place.
> What makes it worth having to spend a day or two on a custom solution?
It's not "custom", it's just a TCP connection.
I quoted a day or two as a maximum estimate, assuming someone totally unfamiliar with the space, and possible integration issues with their existing infrastructure. I'd be surprised if Urban Airship was fully integrated any faster, since most of the heavy lifting will be in managing state and creating an internal push API, not in speaking TCP+SSL to Apple.
This is ostensibly a professional engineer, and this position drives me bonkers ("not HTTP, too hard")!
Apple provided protocol documentation and a very, very simple TCP+SSL protocol. Rolling your own client should be a matter of a day or two of work, at the absolute maximum.
Apple even provides sample code: http://developer.apple.com/library/mac/#documentation/Networ...
The fact that people are frightened of TCP and a simple binary protocol is a mind-boggling indictment of the ineptitude and inexperience of the engineers that have been placed in a position of responsibility.
I dealt with a server team recently that refused to consider a push-based feature because it would "cost too much to send that many pushes through Urban Airship". Implementing their own local client for the protocol never occurred to them, and our doing so for them dismissed out of hand ("too complicated").