Linked by Thom Holwerda on Thu 9th Aug 2007 21:11 UTC, submitted by rx182
Mono Project When Microsoft chief software architect Ray Ozzie unveiled Silverlight at MIX07, he vowed that it would be a cross-platform technology. It appears as if the software giant is making good on that pledge: SD Times has learned that some of Microsoft's top developers have provided technical guidance for a Linux implementation of Silverlight.
Thread beginning with comment 262248
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: i have that feeling
by PlatformAgnostic on Fri 10th Aug 2007 03:53 UTC in reply to "i have that feeling"
Member since:

Perhaps you can explain the mechanism for this break? You have a piece of software on a server which gets downloaded to a Linux or Windows client to run in the browser. Now, there's a small update in one of the clients that somehow causes the other clients to break. How can this be? Are you saying that they'll make an update to the Windows client to suddenly DDoS all the linux clients or something?

Or do you just have no idea what you're talking about?

Reply Parent Score: 2

RE[2]: i have that feeling
by smittal on Fri 10th Aug 2007 05:46 in reply to "RE: i have that feeling"
smittal Member since:

I think the idea is that Microsoft will update the Silverlight API/File Format and free implementations will lack this new functionality and no longer be compatible.

This is the "extend, extinguish" part of the embrace, extend, extinguish trifecta.

Reply Parent Score: 2

PlatformAgnostic Member since:

Existing software certainly won't break in this scenario. And if Linux or Mac compatibility is really important to the content-producers, then they won't use the new features until they're fully supported. Heck, those content producers have to also consider Windows users of the previous versions....

People who talk about EEE really don't understand backwards compatibility and likely don't really understand ABIs. You can't extend and extinguish something without providing compelling features. Otherwise no one would use those extensions. Or if the extended features aren't important in comparison to compatibility, then people will still use the base profile.

The whole EEE thing with Java was particularly funny: Sun made Java hard to interface with the native system for some reasons (they wanted to use Java to lift programs off the underlying OS so that they could shift people over to a SunOS). When Microsoft extended Java to make it easier to call into native Windows functionality and programs, Sun cried foul. Of course, a developer could easily see where their code was breaking portability and could isolate that code if they so chose and they could do all the same things (albeit inconveniently) with JNI. But then there was a cry of EEE.

What we had was Microsoft making something better in a way that the original authors did not want to (for strategic or political reasons). They got sued for it and people hate them for this. But they did embrace the original protocol or system, and their support for it would be unpopular if they did not support the baseline extant specification. The upshot is that you should adopt Microsoft's more popular extensions to your protocol if you want your implementation to survive. Why should it be any other way? If they're providing something that is compelling to their customers, it might be compelling to yours too.

Reply Parent Score: 2