Bill Boulware to iPhone show details 9:18 PM (10 hours ago) www.appleinsider.com iPhone Push Notification Server tied to Snow Leopard Server By Prince McLean Published: 09:00 AM EST * Related AppleInsider articles: * Inside MobileMe: iPhone's Exchange alternative... * Inside MobileMe: iPhone Mail * Inside MobileMe: Apple's Push vs Exchange,... * Inside MobileMe: Mac and PC cloud sync and... * Apple's iPhone takes on the Enterprise Despite licensing the proprietary ActiveSync Exchange Server protocol from Microsoft for use with the iPhone, Apple is building its own Push Notification Server for messaging services in both the iPhone and Mac OS X Snow Leopard Server using open, interoperable standards. However, the company's pioneering, yet protracted leap into push messaging indicates that notification technology can be more complex that it seems, having delayed Apple's intended deadline for shipping PNS by many months. The push for push messaging Push messaging relates to information that is sent immediately rather than queuing up on a server, waiting to be picked up. In conventional email, delivery is always push; sending an email immediately pushes it to the server using the outgoing email SMTP service. The client can always push out email because it knows where the SMTP email server is supposed to be. In contrast, the incoming POP3 or IMAP mail server doesn't typically track the location of the email client, meaning that new emails sit on the server until the client system manually checks for email. This polling process (Apple calls it "fetch") is often set to occur on a schedule, as often as every few minutes. With mobile devices, having to rapidly poll for new emails on the server results in frequent network connections that usually result in discovering that no new emails are available. The original goal of push messaging was to provide battery savings for mobile devices by having the server track the location of the device so that the server could both push out updates immediately and only when necessary, sparing the mobile device from having to fruitlessly poll for data to stay current. RIM vs Microsoft in push messaging The added luxury of having the server track the location of email clients came at a steep price: RIM's highly profitable BlackBerry empire was not built on hardware sales, but rather from service revenues related to licensing its BlackBerry Enterprise Server (BES) software, which is used to track mobile devices and relay them new messages from the corporate email system as they arrive. Microsoft's Exchange ActiveSync (EAS) software (which has only its name in common with the company's unrelated desktop sync tool) duplicates the role of RIM's BES as an add-on mobile device tracker for facilitating push messaging. Both systems also allow IT administrators to manage the devices they track, limiting the software users can install or remotely wiping a lost or stolen unit, for example. Apple licensed Microsoft's EAS for iPhone 2.0 rather than introducing its own competing push system, a decision which made the iPhone immediately useable for many businesses who already owned EAS infrastructure, or at least already used Exchange Server and could easily set up EAS for use with the iPhone at no additional cost. Apple pushes back with MobileMe At the same time, Apple also completed its own push messaging system for use with .Mac and delivered this alongside EAS in the iPhone 2.0 update. The new cloud push service and the existing .Mac services were fused together to create MobileMe, which allowed home users to enable push messaging on the iPhone without needing an Exchange Server account. In contrast with Microsoft's soon to be officially unveiled My Phone for Windows Mobile users (formerly known as SkyBox), MobileMe supports users' existing email accounts and contacts and also provides data sync with their desktop apps, in addition to web hosting and video uploads. When an iPhone is set up to perform push messaging with MobileMe, it registers with Apple's cloud servers, which then track its location on the network so that new email, contacts, calendar, and browser bookmarks can be immediately delivered over the air the instant they change on the server, without continuous polling by the device. MobileMe can also push updates to desktop client computers that register with the service. On Mac OS X, once users enable push messaging, the system registers its location with Apple's cloud servers and updates are pushed to Sync Services, which then distributes the updates to Address Book, iCal, Safari, and any other apps that register with that system. On Windows, iTunes handles the syncing of contacts, events, and bookmarks via a Control Panel interface, and sends new data to the configured Windows apps. Email push messaging doesn't require messages to run through Sync Services (like calendar and contact updates) because the incoming email IMAP- IDLE service supports the ability for the client to inform the server that it will accept new message notifications. This means that rather than pushing the entire email to the client, the server sends a notification of new email when it arrives at the server, giving the client software the option of downloading it immediately. This is more flexible than a straight push, because the system may want to delay the downloading a large email, particularly if the system is mobile and the user only wants to download full messages when a fast connection is available. Apple's Push Notification Server Last year, Apple introduced plans at WWDC to provide a third push mechanism for the iPhone, in addition to EAS support and MobileMe. Rather than pushing updated contacts or calendar messages, the new Push Notification Server (PNS) would allow third party developers to push notifications of any type to the iPhone, which would then badge the application's icon, alerting users that the application had new information waiting for it. iPhone Apple's long-lost Push Notification Service would funnel notification data from third party servers through its own, and then on to users' iPhones. That application, once started, could then download (or offer to download) whatever new data the notification server had alerted it to. For example, an IM provider might push notifications of new messages to the iPhone in order to badge its specific IM app. A mobile app that presents news, stock events, or some other information via an RSS feed could similarly be badged by the developer via PNS. PNS was intended in part to allow third party iPhone apps to reflect regular new updates, pushed over the air, without the apps actually needing to stay active in the background listening for updates themselves (and eating up memory and processor cycles while waiting around). Instead, the iPhone would triage all the push notifications itself and badge the apps' icons so users and developers could both benefit from push notifications as efficiently as possible, and without developers needing to implement their own notification system. iPhone Originally due last September, the service would allow iPhone developers to push three kinds of notifications to users' iPhones: badges, alert sounds, and textual messages. However, Apple indicated that PNS was supposed to ship by last September. That deadline came and went, and the service was never rolled out. Apple released a developer seed with a PNS API, but the company noted that "this API is not yet integrated with a live push server." It appears that PNS ran into unforeseen complications. Apple hasn't given up though; the company itself uses a notification system to push badge updates on the App Store's icon, which then has to be launched to check with the iTunes server of what those notifications actually are, behavior identical to that described for PNS. With the App Store icon, neither the actual software updates nor even their descriptions are automatically pushed to the phone; its badge is simply incremented by, presumably, PNS. However, the system isn't yet fully operational even for internal use; sometimes apps are available but aren't reflected with a new badge increment, and sometimes the badged number doesn't match the software updates that are actually available. Apple has been working similar kinks out of iTunes, which also tracks available iPhone software updates with less than perfect results. The progression of a notification badge being sent from a server belonging to a third-party iPhone developer to an iPhone running the developer's application. Apple has historically allowed a number of technologies to languish as it focuses on the most promising and profitable products to invest its resources in. That's good news for anyone wondering if the company's PNS will ever see the light of day, as the company has so much riding on it. Unlike Apple TV, iCal, and other projects that seem to have taken a long time to develop as back burner hobbies due to the lack of any real revenue stream to justify their development, Apple's PNS is directly related to immediately profitable, high priority projects from the iPhone to MobileMe to iTunes to Snow Leopard Server. archived from misc.phone.mobile.iphone

"An Apple A Day Keeps The BlackBerries Away!" <vic.healey@gmail.com> wrote in message news:48c04c9a-7f9f-4fe5-944c-9d5aebf4df82@e1g2000pra.googlegroups.com... > Bill Boulware > to iPhone > > www.appleinsider.com > > iPhone Push Notification Server tied to Snow Leopard Server > > Email push messaging doesn't require messages to run through Sync > Services > (like calendar and contact updates) because the incoming email IMAP- > IDLE > service supports the ability for the client to inform the server that > it > will accept new message notifications. This means that rather than > pushing > the entire email to the client, the server sends a notification of new > email > when it arrives at the server, giving the client software the option > of > downloading it immediately. This is more flexible than a straight > push, > because the system may want to delay the downloading a large email, > particularly if the system is mobile and the user only wants to > download > full messages when a fast connection is available. On Windows mobile devices, IMAP push is available via 3rd-party software. Avoiding large email downloads is easily controlled in the device's standard messaging app- you can define an upper size limit of emails to download automatically (truncating larger ones until you ask for them) and choose if you want attachments to be downloaded automatically, and if so, up to what size you want automatically to download. > Apple's Push Notification Server > > Last year, Apple introduced plans at WWDC to provide a third push > mechanism > for the iPhone, in addition to EAS support and MobileMe. Rather than > pushing > updated contacts or calendar messages, the new Push Notification > Server > (PNS) would allow third party developers to push notifications of any > type > to the iPhone, which would then badge the application's icon, alerting > users > that the application had new information waiting for it. > iPhone Yeah, that's SO much easier than just letting your IM client to run the backgroud... > Apple's long-lost Push Notification Service would funnel notification > data > from third party servers through its own, and then on to users' > iPhones. > That application, once started, could then download (or offer to > download) > whatever new data the notification server had alerted it to. For > example, an > IM provider might push notifications of new messages to the iPhone in > order > to badge its specific IM app. A mobile app that presents news, stock > events, > or some other information via an RSS feed could similarly be badged by > the > developer via PNS. > > PNS was intended in part to allow third party iPhone apps to reflect > regular > new updates, pushed over the air, without the apps actually needing to > stay > active in the background listening for updates themselves (and eating > up > memory and processor cycles while waiting around). Instead, the iPhone > would > triage all the push notifications itself and badge the apps' icons so > users > and developers could both benefit from push notifications as > efficiently as > possible, and without developers needing to implement their own > notification > system. What word does Apple use for "kludge"? archived from misc.phone.mobile.iphone