Yep, in the end there is still a pretty simple protocol between the phone app the watch. So it doesn't really matter where the data is coming from, as long as the phone app understands it and can send it.

The advantage of Pebbles setup is that, as you already set MikeHG, the phone app doesn't need to constantly poll all the services if data has been updated. It just needs to poll the Pebble servers. This makes the communication a lot cleaner, and doesn't drain the battery that much (as there is less chatter over wifi or 3G, and the phone doesn't have to wake up for every individual service). This is kind of the same as the push notifications which you're required to use on iOS, and Googles counterpart which can be used on Android.

And besides the simplified communication it means you don't need a lot of native apps which push all the data to the Pebble. As long as the "data provider" can push the info to Pebbles servers, the watch should be able to show the data, as long as there is a Pebble phone app which supports this. This compared to none strict protocols as Atom/RSS feeds where the data can be put into different fields, and you thus possibly still need support for different Atom/RSS feeds based on the data provider.

And you're right about the calender. This can be handled locally. The phone app just needs to read the calender and send the events to the Pebble. It's not like the watch itself queries the phone app to get the data, but the phone app is always in charge. The phone app just says something like "can you add a pin on 1 sept at 19:45 with subject X and body Y", and were all the data is coming from is up to the phone app. So it could either be read by the phone app from for example the calender, or queried from Pebbles servers, or send by some app which is running on the phone, which would relay the message using the Pebble phone app.