Are all (Microsoft and Apple) sync services created equal?
Summary: Apple's introduction of the successor to .Mac -- a k a, MobileMe -- raises the question as to what's taking Microsoft so long to roll out Live Mesh.
Apple's introduction of the successor to .Mac -- a k a, MobileMe -- raises the question as to what's taking Microsoft so long to roll out Live Mesh.
There aren't a whole lot of details yet available on MobileMe, other than that it will allow cloud-based synchronization of data and devices. (And will make use of Microsoft's ActiveSync technology, which Apple licensed from Microsoft in order to bring push e-mail to the iPhone, creating its "Exchange for the rest of us.")
From initial reports, MobileMe sounds like a combination of a Windows Live (the various Webified versions of the .Mac point products), Live Mesh (the Mobile Me sync service) and SkyDrive (the Mobile Me cloud-based storage). It is slated to be available to customers in July for a (pricey) $99, which includes 20 GB of storage.
Given that Live Mesh is only in very early test at this point, there's no word on how Microsoft is planning to package/price the service. Windows Live services are currently free, as is the beta of Windows Live SkyDrive, which includes 5 GB of free storage. Microsoft has not provided even a calendar year target as to when it will make Live Mesh available commercially.
Meanwhile, Live Mesh is not Microsoft's only synchronization/collaboration service under development. Microsoft's Sync Framework, a mobile-client test version of which is due in the third quarter, is another.
Last week, at Microsoft's TechEd Developer Conference, I tried to get Microsoft execs to articulate more clearly the overlap/connections between Live Mesh and the Sync Framework. I realize that Live Mesh, as far as Microsoft has been willing to explain it, is more of a consumer-focused platform that will have a developer aspect (via the forthcoming Live Mesh software developer kit).
But why didn't Microsoft's Live Mesh team use the Sync Framework as an underpinning? Wouldn't that have helped Microsoft get Live Mesh to market more quickly -- a la Apple -- than it will be able to do by creating the entire Live Mesh stack from scratch? No word was forthcoming from the Softies. All I could get out of them was Live Mesh is the P2P, out-of-the-box sync solution and Sync Framework is the customizable, developer-focused sync solution. The only place (so far) where the two meet: FeedSync.
Microsoft is (in)famous for pitting its own development teams against one another, allowing the "best" solution to win. I wonder whether this is what is happening with Live Mesh and the Sync Framework. If not, why didn't the Live Mesh team make greater use of what's available and coming with the Sync Framework? Theories? Thoughts?
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
It is!
The Sync Framework is the ATOM/RSS/JSON middleware that provides the underpinning for partially connected clients.
I have to agree about your general point. Live development in general seems to be going in slow motion.
based on sync framework?
I don't think it is. I gave Microsoft ample opportunity to say the two were connected. They did not -- and would not.
Look at this architectural diagram Microsoft gave me: http://blogs.zdnet.com/microsoft/images/mesh-developer-stack-slide.jpg
I think the commonality between Live Mesh and the Sync Framework is FeedSync, not the Sync Framework.
So back to my question: Why didn't they base Live Mesh on the Sync Framework? It seems as though both are making use of similar protocols. But they are two different and disparate things. MJ
Live Mesh *IS* build on Sync Fx which *includes* FeedSync
> I gave Microsoft ample opportunity ...
1. What happened to investigative journalism?
2. Get better contacts at Microsoft.
Or at least spend a tiny bit of time on Channel 9:
http://channel9.msdn.com/shows/Going+Deep/FeedSync-Synchronizing-the-Mesh/
The relationship between Sync Fx and FeedSync was also discussed at Mix 08:
http://visitmix.com/blogs/2008Sessions/T32/
Since you attended Mix in person, I have to assume you should have spent less time at the slot machines in Vegas.
Trying to be constructive, I guess you can see it like this:
- Live Mesh is the app or connectivity "OS" shell
- Sync Fx is the API
- FeedSync is the protocol (which is "open" and can be implemented by others, e.g. Novell)
The people in first video linked above may be able to give you a better summarizing quote, but whatever it makes NO SENSE to see Live Mesh, Sync Fx and FeedSync as 3 different *products*. It's bad enough already with the older synchronization products like SkyDrive and FolderShare, but I guess we'll hear at PDC that they will be discontinued.
P.S. I just noted that even Wikipedia has a decent description of Sync Fx vs. FeedSync (and of the whole lower level stuff): http://en.wikipedia.org/wiki/Microsoft_Sync_Framework .
Mary Jo, I understand that saying "Google is your friend" would further worsen your relationship with MSFT PR, so just think "Wikipedia and Channel 9 are my friends".
Drilling in
sorry for the harsh words above -- I'm starting to understand where your confusion come from.
The following was written by Microsoft employee
Richard Chung:
"The Sync Framework is compliant with FeedSync, in that data that is synchronized via FeedSync can be synchronized by the Sync Framework and vise-versa. FeedSync is a set of extensions defined in this specification that allow synchronization, and not actually a shared code library (though implementations certainly could be shared). Live Mesh is built with FeedSync ingrained in the system with its own implementation."
See http://forums.community.microsoft.com/ru-RU/LiveMesh/thread/da504fcd-b3d6-45a5-b460-b4f478b5635f
(Links says ru-RU, but they talk in English).
So let's re-iterate:
- Live Mesh uses the FeedSync protocol
- Sync Fx uses the FeedSync protocol
- Sync Fx on one computer can talk to Live Mesh on a different computer ("compliant")
- A Live Mesh API will need functionality beyond Sync Fx, e.g. to address creation of "Mesh Folders".
- Sync Fx can also synchronize SQL databases,
which is not a Live Mesh functionality.
- My guess is that Mesh API very close to Sync Fx, where functionality identical.
Live Mesh to me is very much a shell-level end-user application (also in feature set), which requires using Live ID, which is not acceptable in an enterprise. The Sync Fx API, on the other hand, allows programmatic synchronization way beyond simple file sync. For example, with Word using Sync Fx, you and Larry Dignan could be editing the same document at the same time -- with changes showing up in the other's window.
Or a mobile camera could send pictures into a database (similar to the AP app show yesterday for the iPhone) -- see TechEd keynote http://blogs.msdn.com/sync/archive/2008/06/09/sync-to-hosted-services-and-explanation-of-the-bill-gates-keynote.aspx
Back to the original question
But back to the original question. Do you think the Live Mesh team could have/should have used Sync Framework when designing Live Mesh. I understand how the two are related (FeedSync). But both teams are saying that their frameworks are customizable and could be used for consumer and business apps.
My question was just why didn't the Live Mesh team make use of the more comprehensive Sync Fx technology that already exists.
Thanks. MJF
Scalability vs. Feature Set
Live Mesh will need to run on devices(Mac, phones)that present a challenge for the much broader (SQL etc.) feature set of Sync Fx. SQL on a USB stick?
If Mesh is such a critical platform for MSFT as Ozzie, you and I believe, it must scale. And scaling means
1. Performance on MSFT servers (relaying, data storage)
2. Performance on clients, devices
3. Porting to new devices
#1 is outside of the Sync Fx scope (Sync Fx does not require Live). For #2 and #3, I guess the Mesh team considered Sync Fx too feature-rich. My impression from one of the C9 videos was that the Mesh team plans to develop a lot of "native" implementations for the more critical devices.
In some ways this is like still not even planning to develop Office in .NET -- although .NET has a larger feature set.
As a software architect I would be very disappointed if at PDC the core API of the Mesh Operating Environment (MOE) would not have a striking similarity with Sync Fx. (Can't say more.)
"is more of a consumer-focused platform that will have a developer aspect"
They'll move too slowly, and just be a big keep net/vacuum cleaner for those that merely "consume" technology.
The real development over the next 5-10 years will continue to surpass anything MS's shareholder value/control driven agendas can actually provide, perhaps, as I once read, "like a tree growing over a barbed wire fence."
Ok, so we strangely have Apple basing their stuff on a competitors technology - read up on the protectionist phase of the major economies, and welcome to it, recognize it...
The winners will be the dynamic countries/groups etc which don't have their intellectual capital based on a protectionist group of people that need a press release to know what to think.
27 cents a day is not pricey.
It is when you've lost your house and commute 100 miles per day
Obviously it's relative.
What idiot
CLOSER TO WORK. It's not like you have to worry about selling a
house.
Surprising?
MobileMe ? raises the question as to what?s taking Microsoft
so long to roll out Live Mesh."
Yeah MS is a company known for rapidly producing products
and pushing the leading edge of technology;-)
The real question is why more commentators haven't realised
the emperor has no clothes.
Better than the alternative
MS may have no clothes but Apple is just the clothes with nothing underneath. The funny thing about your "emperor has no clothes" comment is that the emperor was [b]still[/b] the emperor, even without his clothes! :)
The real question to me is why more commentators haven't realized that Apple is a pure marketing company that sells nothing but false promises. One only need to spend 30 seconds perusing Apple's support forums to realize that.
Right
haven't realized that Apple is a pure marketing company
that sells nothing but false promises."
Sorry I thought Apple was the company that had products
(available from their store), perhaps time for another MS
win7 article;-)
Isn't Apple also the PC company with the highest customer satisfaction rating in the industry?
I guess for some it is better to make stuff up rather than
actually deliver anything.
Hehe, to continue with your analogy...
The emperor's subjects thought the emperor was just great without his clothes!
Apple gets higher customer satisfaction because Apple consumers hate admitting that they got ripped off. Just look at the behavior of the Apple apologists on ZDNet and you can see that no matter what Apple does, they are willing to apologize for it. iPhone gets 80% satisfaction ratings yet 33% admit that they need to use another phone for basic voice calling and email! Like I said, Apple consumers are liars. :)
you're funny.
Has anyone seen Apple's demos of this?
http://www.apple.com/mobileme/guidedtour/
I know all the security information I need to know
It is offered by Apple, the only company whose OS was hacked within 2 minutes of browsing on the Internet at the PWN2OWN contest. The company that brings you half gigabyte security patches every couple weeks. Thanks but no thanks, there is no way I'm trusting my data with Apple. :)
Ah, Apple.
antivirus software and yet do not have a single Mac virus on
them, and the only widespread virus for it you have to pay
for (Norton).
one day + 2 minutes, actually. (n/m)