Prince McLeanIn an email sent to iPhone developers, Apple wrote, "We have selected a pre-release version of the Associated Press app for iPhone OS 3.0 to create a high-volume test environment for our servers."
The test application, which requires iPhone OS 3.0 beta 5, will be active over the next week and will then expire. During that time, "AP will be sending a high-volume of real news alerts" to give Apple an opportunity to monitor how well the system works and what optimizations can be made.
Originally planned to arrive last fall, Apple's Push Notification system was delayed after the company realized that it had underestimated the demand third parties would make of the system.
After realizing its original design would not adequately serve the needs of developers or users, Apple pulled the plug and returned to the proverbial drawing board to create a supportable system that was up to the task of serving alerts to the audience of tens of millions of iPhone and iPod touch users.
XMPP pubsub and push notifications
Apple's new iPhone 3.0 push notification system for sending alerts from third party application developers to mobile users is believed to use the same technology as its push notification system for MobileMe and the push notification system planned for Mac OS X Snow Leopard Server.
In all cases, the alert being "pushed" is minimal, essentially a tweet that indicates more information is ready. The notification alerts act like an instant message because that's exactly what they are; an analysis of MobileMe push messages indicates Apple is using the open source XMPP (eXtensible Messaging and Presence Protocol), used in Jabber.
In addition to powering basic Jabber instant messaging in products like GoogleTalk and Apple's iChat and iChat Server, the XMPP specification also supports pubsub (publish and subscribe), a feature that enables XMPP clients to post XML data to a Jabber server, and then allows other client systems to subscribe to the node and receive a notification whenever the data changes.
This powerful feature enables all sorts of applications, and Apple's apparent use of it to power everything from application alerts on the iPhone to email, calendar, and contact changes in its MobileMe cloud services and its server product only hints at the future possibilities and potential of the technology.
Apple's extensive use of the open source XMPP pubsub technology also highlights the absurdity of rumors that the company was about to buy Twitter, a private and proprietary messaging system that has been described as "SMS for the Internet."
-m.jpg)
Wesley Hilliard
Malcolm Owen
Andrew Orr
William Gallagher
Sponsored Content
Christine McKee
Thomas Sibilly
30 Comments
It would be nice to see Apple support XMPP for their instant messaging service rather than use the AIM protocol. Would unify things nicely.
I just got my first AP News Push. ZOMG common and well traveled technology works in a new way!!!!!Seriously, I was a bit excited, now lets get it in a more useful app like BeejiveIM and FaceBook.
Won't allow us to play our radios on our existing iPhones though. Interesting, that's about it.
Won't allow us to play our radios on our existing iPhones though. Interesting, that's about it.
Of course not, that will come with background apps in the future. I would have thought Apple would have allowed you to import your iTunes radio into the iPod app so you could stream it by now, but I guess not.
I just got my first AP News Push. ZOMG common and well traveled technology works in a new way!!!!!Seriously, I was a bit excited, now lets get it in a more useful app like BeejiveIM and FaceBook.
Ditto.
However, Apple has yet to tell us how it's going to manage sending lots of notifications to users at once. I mean, if servers get to send a message as often as you'd like, does that mean that you're going to constantly keep getting messages? I'd like to see more granular control on an app-by-app basis (like AIM could be real-time, or delayed by a minute, where as AP would be every 5 minutes or so)
Also, for those that aren't aware, push is limited to 256 bytes minus whatever is used to format the message (sound file names and badge numbers are sent as well as plain text). That means long messages definitely won't be allowed.