Saturday, October 30, 2010

Microsoft Kombat!!!

As I attended last year’s PDC, and especially after the 2nd day’s event, I couldn’t help but feel an enormous amount of excitement and energy around Silverlight.  This “platform within a platform” was touted as the future and that it was a prudent decision to “bet on Silverlight” for your target platform not only for web applications, but for desktop and (then only hinted at) the phone platform.  Silverlight for Symbian was released.  Microsoft was going to make a version of it for Moblin.  Hints of movement on the Android front were not exactly denied.

Funny what can happen in a year.

The other day, I and my team at the office watched the 2010 PDC keynote presented by Steve Ballmer and Bob Muglia.

As Mr. Ballmer sauntered onto the stage and began speaking, I couldn’t help but notice the Silverlight logo conspicuously missing from the banner of products that implied what this keynote was going to be about.

And aside from a very short demonstration of Windows Phone 7, Silverlight was absent from the keynote.

It seems that I am not the only one who noticed this.  Respected journalist, Mary-Jo Foley at ZDNet noticed this very same thing, and asked Bob Muglia about it.

Apparently Silverlight is no longer the cross platform RIA client framework that it was intended to be.  In fact, it looks like it’s now just a little more than the new version of the .Net compact framework.  A talk back participant on Mary Jo’s blog linked to a video where Silverlight evangelist John Papa interviewed Scott Guthrie on the future of Silverlight.  This video echoes the new direction in a far more subtle way.  Apparently desktop focus on Silverlight will be for “certain vendors” and “proprietary” purposes.

I guess that doesn’t mean that Silverlight is “dead”, per say.  It will fill the some niche roles and remain a minor competitor to Flash (at least on the Windows and Mac platforms).  Having used it in an intranet environment, I agree that it’s a great and arguably more stable alternative to Click-Once deployments.  And I know a lot of managers at Microsoft have been quick to play this card of damage control since Ms. Foley’s article.  Simply put though, what did they expect the reaction to be? Given Microsoft’s track-record of rapid change of focus, its hard not to take things at face value during an event designed to give the developers in their eco-system a sense of where things are going.

But in terms of the wider audience for cross platform rich internet applications, it has suffered a fatal blow.  Or in the words of the announcer from the video game Mortal Kombat:  “HTML5 Wins.  Fatality.”

The allegations were true!
About a month ago, a former Microsoft manager on the Silverlight team, Scott Barnes, rang the warning bell of this impending situation via his blog and Twitter.  To be completely honest with you, I initially wondered if this was some FUD-monger tactic of a disgruntled ex-employee.  And a few of the “corporately minded elite” seemed to down play his allegations.  However, after reading his blog entries, I started to develop a different idea about his motive.

Clearly he is/was proud of the work he did at Microsoft. Post-employment, he has even continued to evangelize the framework by offering design solutions to hard problems, such as the install experience.   Further, he has acknowledged the investment so many people have made in Silverlight for what it was promised to be.  Spilling the beans was not a malicious act.  It was an attempt at intervention.  And while it obviously burned a huge bridge in the process, it must have burned in the wake of a clear conscience.

So now what?
I'm a little bitter-sweet about the direction that Ballmer and Co. have taken this.  From a day-job professional standpoint, if you’re like me, it won’t matter a whole lot since Silverlight will still exist in the capacity of what we’re using it for:  Easy to develop and deploy, rich UI intranet applications.  And I guess at some level, it’s nice to know what the “official” direction is, even if it’s not the one I hoped it would be.

However if your audience scope is a whole lot bigger (like my personal off-hours aspirations).  Then you will probably be wandering into the world of weak-typing, non-intellisensed mark-up and “web standards”.

The good of Microsoft’s embrace of HTML 5…
To be optimistic, the jump from xaml/c# to html/javascript isn't nearly as terrible as it used to be.  (Ok, who am I kidding? It still sucks.  Just not in a late-90’s early 2000’s sort of way.)

From a cross platform perspective, this does release Microsoft from the burden of implementing a Silverlight player on all the platforms out there. Nearly every platform out there with a web browser will most assuredly make it HTML5 compatible at some point.  This also means that all the outcry for “Make Silverlight for iPod/iPad/iHateFlash” and “Make Silverlight for Android” all becomes someone else’s problem.  And while the wheels at the W3C do turn slowly, they do turn, and it’s direction is kept in check by the competing agendas of Microsoft, Apple, Google and anyone else on the advisory board (which is a good reason why it’s adoption of standards is so slow).

Comparatively, perhaps the notion of support for multiple platforms for Silverlight was too ambitious of a goal to begin with.  James Gosling of Java fame implied in a recent blog entry that most OS-implementations of Java were managed by the OS owners themselves.  Adobe’s has had Flash for years, but it wasn’t until recently that they made any major attempts at leveraging it as a cross platform framework.  And even then, this was prompted only because Apple’s market share for casual web browsing was threatening to put blue legos in all of Flash’s website airspace.  If you read between the lines of Muglia’s comments to Mary-Jo, they are throwing in the towel for Silverlight in recognition of that same insurmountable threat.

I know I'm not the first to suggest this, but perhaps a way of re-structuring of Silverlight so it outputs HTML5 rather than CIL isn't such a horrible idea.  Of course, this would probably cripple the Silverlight C# implementation enough to call it an entirely new product.  Maybe something akin to a client-side focused ASP.Net development environment.

Hey, it’s wishful thinking.  And Microsoft is probably not the company to do that job since there will be a temptation toward IE9+ bias.  But it would be a totally rocking product if done responsibly.

The bad of Microsoft’s embrace of HTML 5…
If you paid attention to the keynote demonstration, Mr. Ballmer exalted the virtues of HTML5 standards, and gave exuberant praise of how well Internet Explorer 9 handles the content.

I say I have to agree with him there.  The folks on the Internet Explorer team have done a fantastic job making HTML5 content as snappy and responsive as any Silverlight or WPF application I’ve seen.  Kudos to them for raising the bar high and challenging competing browsers on Windows as well as other platforms to match the experience it provides.

However, after praising the benefits of following the standards, he proceeded to drop hints of how IE9 will “enhance” the HTML5 experience for Windows 7 users.
One can’t help but think that the EEE snake is rearing it’s head again with the notion of application “jump lists”.  If you watch the demonstration carefully, the Windows 7 Javascript APIs carry a Microsoft naming convention.

You have to ask yourself, what if you’re running this Javascript in a browser that’s not aware of the Microsoft APIs?

Even if Microsoft were to make these APIs available to competing browsers on the Windows platform, what happens on the iPad?  Or on Android? Or the Wii? (Though I suppose some may argue that these platforms will have their own specific APIs as well)

What if another OS implements a means for “jumplists”?  Is the Microsoft Javascript encumbered by patents?  Will there be multiple “jumplist” APIs made by different OS providers? What a mess.

But since Windows is the dominant platform on the desktop, there’s a big danger and temptation to encourage web developers to assume that IE9 will be the browser to target.  Those of us who have been around for awhile will know that we should also test in competing browsers as well.  Given the myriad of capability testing one has to do when making an HTML5 page, it’s very easy to take the easy way out and write the pages to not bother to check.

Microsoft knows this, and as a company full of developers, they know fully well that the average developer (and there are a LOT of average ones out there) will likely opt for the easy path rather than the best practice.

The Ugly inconsistency of HTML5
The interpretation of "standards" is pretty loose.  Basically in the case of HTML5, it’s a list of specifications that a browser should implement. A browser claiming HTML5 standards doesn’t necessarily have to implement every specification (thus the need for capability detection).  And unfortunately, there is no “standard” for performance.  This means that all HTML5 frame rates will dramatically differ, particularly on underpowered devices such as phones.

To put it in perspective, my Android handset running Éclair does HTML5 in it’s standard browser, but not particularly well. It is slow, and sluggish.  I imagine this is due to the lack of hardware acceleration.  In these scenarios, it would be desirable to avoid HTML5 altogether. I’m not sure if the slowness has been addressed in Froyo since Sprint isn’t letting me go there without rooting my phone and voiding my warrantee.
I have also heard of similar complaints on the iPad.   And again, I’m not sure if this is addressed in the coming upgrade of that product’s OS.

Presumably, this will all be easily corrected in time by allowing these platform browser’s access to the hardware like Internet Explorer 9.  But until then, the HTML5 experience across platforms is going to be inconsistent and spotty.  Same as how HTML has always been.

More follow the leader…
In conclusion, I can’t help but speculate what happens next at Microsoft.
Recently, Mr. Ballmer said that Windows 8 will be Microsoft’s riskiest product bet.  Some of the things mentioned were “instant on”, an “app store”, integration to cloud services..

Couple this with Office 365 and the demonstration of IE9, which seemed to make IE9 less of a browser and more of a “virtual desktop”, one can’t help but draw similarities between what Windows 8 might actually be and another operating system brewing out there.  If Windows 8 is a “cloud client OS” that simply boots into IE9, that would certainly qualify as a risky product bet.

So is Windows 8 a successor to Windows 7, or a light-weight sister product similar to Chromium-OS?  My guess is that it will be the latter.  Windows 8 will be aimed at the casual user as a means of consuming Azure, and Windows 7 will be for advanced  users such as those that do software development.
If this is true, the sudden love affair with HTML5 makes a whole lot of sense:  they are paving the path for their next version of Windows.

Sunday, October 24, 2010

PDC 2010 Predictions: The future is soon!

Microsoft Professional Developer's Conference starts this week.  Amazingly, this conference sold out only 5 weeks after opening.  Compare this to last year, where I was able to secure a spot there within a couple weeks of it’s first workshop day.

I wasn’t quick enough this year to secure a spot, but for those of you who were lucky enough to get a spot, PDC allows you to participate in a bit of Microsoft history.  PDC and MIX tend to bookend implied direction of Microsoft’s strategy.  Those of you who are like me and unable to make it this year, the PDC website is going to have live streaming.  Hopefully since Steve Ballmer is doing the keynote, we’ll see “Developers!: The sequel”.

It’s always fun to speculate based on the events of the past and news items that have floated around for awhile.  So here are a few things I think we will see this coming week before PDC comes to a close:

The No-brainers
Windows Phone 7 development will be a huge focus, as will Azure.
Heck, this isn’t really so much of a prediction as it’s mostly confirmed by the agenda at the PDC website.  But it will be pushed heavily through the magic of the mind control devices strategically placed in the auditoriums on the Microsoft campus as well as peer pressure from the well respected “who’s who” of the Microsoft development teams.  In all seriousness, these items have been and will be big deals to Microsoft’s future.  So therefore, they will get a lot of attention.

Certain limitations that exist within Azure right now, such as limited ability of customizing the virtualization images in your “spun up” farm drones, will probably be lifted with new announcements around this platform.  Hopefully a new pricing model will be announced as well or some analysis tools to give companies an idea of how much a cloud-based application will cost them.  As it is at the moment, it’s far too easy for an application in the cloud to cost a lot of money unless that application is optimized to minimize it’s dependencies on cloud transactions.

I believe the next version of the Windows Phone 7 operating system and Silverlight/XNA development tools will be announced as well.  Bringing it closer to Silverlight 4, and closing at least some of the criticized gaps in functionality that the launch version of the OS has.  I also predict that these upgrades will go beta for public consumption and testing with the goal of making it available on the handsets in time for WP7’s wider release to carriers that do not rhyme with Bay-Tee and Tee.

The ultimate in swag: Part II
Those that attended last year got the ultimate in swag: A limited edition Acer Aspire 1420P laptop, filled with features that allowed developers to exploit the new snazzy APIs that were revealed in the also announced Silverlight 4.  Continuing in that trend, I predict that developers will receive free phone hardware to assist them in writing Windows Phone 7 applications.  I’d also not be too surprised if attendees were to get a voucher waiving the first year’s $99 fee in the application store.  They do this already for the Dreamspark students, so it doesn’t seem too far-fetched to give the same opportunity to those who take their development efforts seriously enough to pay money to participate in a Microsoft conference.  In other words, if they HAVEN’T thought of this as a give-away.  They really should.  (And this is coming from a guy who won’t be there to reap the benefits of such giveaways)

Silverlight: the new Borg
The next version of Silverlight/Everywhere will be announced for PC and Mac. (Silverlight 5)

WPF will be officially dead (as previously alleged elsewhere).  Although “dead” in this case will just be a synonym to “rebranded” or in Borg-speak "assimilated".

Lately, Silverlight’s true definition is a little fuzzy.  What was originally intended to be a “code once, deploy many” type of framework, has turned into more of a clever marketing buzzword.
And in keeping with this trend, “Silverlight for Windows” will be the newest flavor to join the likes of “Silverlight for Windows Phone”, “Silverlight for Symbian”, “Silverlight for Windows Embedded”, and “Silverlight for your toilet” (Okay. Just kidding about that last one, I hope).  The book publisher of “Silverlight for Dummies” may have to change the name of their book to avoid potential confusion for those who may ultimately seek to develop for the “Dummies” platform. (which, in a way, would be somewhat ironic. Insert your iPhone/Android joke here.)

On the other hand, Silverlight 5 may be enough to mark the end of further WPF development.  Like the COM capabilities introduced in Silverlight 4 through the “dynamic” keyword in the new .Net and Silverlight APIs, it’s probably not too far off to allow .Net assemblies a point of entry in a Silverlight application in nearly the same way.  In fact, you can bring in .Net assemblies today by leveraging some COM objects already built into Windows/.Net.  Silverlight just needs a more straightforward way to do it. This gives existing applications that sit a little closer to the .Net metal a migration path, and still allows a common Silverlight codebase.  Of course, this would have to exist under the blanket-centric “elevated trust” model, which has it’s own issues (as I ranted about here).

Silverlight expands 3 Screens and a Cloud.
Three screens and a cloud reveals it’s 3rd screen
Last year, Ray Ozzie evangelized his vision and strategy of leveraging the cloud as a service provider for browser and rich client plugins:
“So, moving forward, again I believe that the world some number of years from now in terms of how we consume IT is really shifting from a machine-centric viewpoint to what we refer to as three screens and a cloud:  the phone, the PC, and the TV ultimately, and how we deliver value to them.”
-Ray Ozzie 
With WP7, Zune, XBox 360, and Windows already able to consume XNA applications, one could argue that XBox 360 was already part of the 3-screen trifecta.  However, XNA’s purpose is nearly exclusive to gaming, doesn’t provide a standard UI for applications, and it’s application focus has not been one for consuming cloud content.  This doesn’t fulfill the true vision of applications AND games being represented on the three screens.

Rumors have been circulating for awhile that the Xbox 360 Dashboard’s 2010 update this fall (which I believe will be shortly after PDC) will have the “Indie games” area renamed to “Xbox Live Apps”.  XBox Live’s new dashboard looks to be heavily influenced by the Metro design standards.  And such a rename would imply that XBox would be the conduit to the television “screen” for more than game applications. It just seems more than a coincidence.

So, I suspect “Silverlight for XBox”, coupled with a renaming of the Indie portal on XBox Live will be the defining moment of the third missing screen in Mr. Ozzie’s vision and strategy.  This will be monetized the same way the Indie game developers and WP7 developers are charged now:  As development partners for the app store.

The PC screen gets bigger… (or rather, deeper)
Some time ago, Microsoft’s Silverlight team announced a collaboration to bring Silverlight to the Linux based open source Moblin operating system destined for their Atom-based netbooks.

There was even a live demonstration of Silverlight 3 in action on a Moblin netbook given at an Intel convention by (then) Microsoft General Manager Ian Ellison-Taylor (who recently resigned from Microsoft as well).

In parallel, Nokia was working on a similar mobile open source operating system called Maemo.

Recognizing similar philosophies and goals of targeting mobile and netbook devices, Nokia and Intel merged the projects and it became Meego.  This new hybrid project has basically been a mash up of the best features, and strengths on the two systems.

So where does Silverlight fit into all of this?  I posed that very question at the Meego forums, presenting all the evidence and questions around Silverlight’s implementation on the Moblin OS.  The result was a couple of friendly responses from community members.  But neither Nokia nor Intel’s people have commented.  In the course of 2 months, my post gathered over 800 views, which I think implies some interest for Silverlight on this platform.  And such popularity deserves a comment by someone “in the know”… unless they are forbidden to prior to official announcements.

A few changes at Nokia as a company point to this platform being a new home for Silverlight as well:

A former Microsoft President, Mr. Stephen Elop is now CEO of Nokia.  In announcing Mr. Elop’s departure from Microsoft, Steve Ballmer casually mentioned a continuation of a working relationship with him at Nokia.

Of course, this could mean something simply in the realm of a manufacturing agreement for Windows Phone 7 hardware.  Or it could mean that “Silverlight for Symbian” will be getting an upgrade sometime soon.

However, it’s been mentioned that Meego may be the operating system of choice on Nokia smart phones in the future.  And recent news implies that the Symbian foundation itself is facing a little bit of trouble.

So that really leaves Meego to be the platform successor for “Silverlight for Symbian”.

Just like last year, I expect the free software version of Silverlight (Moonlight) to be given an ultra quiet nod as well.  I suspect that Moonlight 3 will finally be released out of it’s preview state to either a beta or production release.  I would also expect to see the “Ahead of Time”/N-Gen compiling option getting added to Moonlight sometime in the future to give Silverlight an equivalent deployment strategy to iPhone as Adobe currently provides with Flash/Air. 

What we won’t see…
Silverlight for Android handsets
So what will NOT be making an appearance at PDC?  I highly doubt we will see anything resembling “Silverlight for Android Phone” outside of anything that the Mono/Moonlight team at Novell may have brewing.  Why? Such an announcement would take the wind out of the sales (ha, get it?) of Windows Phone 7.

While Microsoft has not denied any work in the area of Android, the timing for this is not correct (at least on the smartphone/ARM version.  More on this in a minute)

Best bet would be some announcement at MIX11 if there’s a strategy in place to monetize application deployment similarly to WP7 without hurting WP7 momentum.  And even then, I doubt support will be a priority if only out of respect for their partnership with Nokia/Symbian/Meego.

Silverlight for iPhone
Big surprise?

The long shot: The app store bandwagon
I know this might seem WAY out there, but if you were at PDC last year, eBay was given some airtime during the keynote to tout their “App store” to allow Silverlight 4 developers to monetize their development efforts.

I suspect we will see a similar product announced as an agreement between Microsoft and Intel.
Intel’s AppUp developer sales portal is already live, and it’s very possible that it’s going to be heavily promoted through their OEMs on all Intel devices in the near future.

AppUp currently supports .Net applications for Windows, Moblin has an SDK, but I imagine that’s just going to remain there until the Meego SDK is announced (which will probably also work with the Moblin deployments out there that just won’t go away).  Silverlight support has also been noted on the roadmap.
If this is true, Miguel de Icaza's Windows App Store idea might actually take some shape here, even if not specifically managed by Microsoft themselves.

So what’s in it for Microsoft?  If a partnership is in place here (and there is suspicion that one already is based on this little "top-secret" exchange), it means plenty of opportunity for monetization.  Monetization in the form of some sort of profit sharing agreement, perhaps.  Or, Azure could simply be providing the hosting for the applications.  Hosting costs as well as download “transactions” equate to dollars (or rather, many, many cents) in Azure’s typical billing agreement.  This means that “cross platform” platform strategies such as Silverlight existing outside of the Windows eco system widens the audience and revenue stream for these downloads.

This also figures into Mr. Ozzie’s strategy.  Let’s not forget that Silverlight applications, regardless of the platform it runs from, is a good catalyst for cloud transactions from within the applications themselves.  And as Microsoft knows, money that doesn’t originate from an application running on Windows is just as green as one running from Meego... (or a tablet based Android)

Android support without disrupting WP7?
Intel has been working on an Android tablet running on the Atom processor.

One of the things that many people do not realize about Android is that while it is an “open” operating system, there are a few key closed applications that Google reserves for their licensed handset partners.

One such item is their App Store browsing application.  This is a very important application currently.  However, if Intel has it’s own app store, and has it’s own application for browsing it, I don’t imagine it’s too far fetched to allow Android applications to exist on AppUp as well and offer this to OEMs as a free/subsidizing alternative to Google’s store.

And if the only applications that exist on this store are Android netbook applications running on a version of Silverlight for x86 Android, this doesn’t necessarily interfere with Windows Phone 7 since the Android handsets run on the ARM/Snapdragon processors.  In fact, the netbook version of Meego’s Silverlight (if it exists) probably ports to the x86 version of Android with little effort due to their common Linux roots.

In conclusion, its worth noting that Ray Ozzie has not been mentioned as a keynote speaker this year.  Clearly this is due to his recent announcement to leave the company.
So who should succeed Mr. Ozzie?

PDC is a great place to make this announcement if it’s someone that Microsoft KNOWS that the development community will approve of and get behind.  If anything, Microsoft knows how to market to it’s developers.

So.. will the next chief software architect hire be a Jobsian move, and bring Bill Gates back?  I doubt it.  If an announcement is made at all, I’m personally betting on the red shirt.

To all of you attending PDC this year, have a good time!  I can attest that 2009’s was one of the best events I’ve ever attended.  Be sure to wave on the web cast.  I’ll be looking for you.

Sunday, October 17, 2010

Silverlight 4 “trusted” out of browser: The new ActiveX?

Silverlight 4 is a tremendous leap forward in functionality.  
We get webcam support.  Printing support.  Improved DRM if you're into that sort of thing...
Elevated permissions to make slightly more powerful applications (in terms of what the application is allowed to do).
But, in a move that seems pretty unrestrained from the Microsoft Silverlight team, and especially with the introduction of COM automation, the power of an elevated permission nears that of a full blown desktop application.

And like all great powers, this can be used for both good and evil.
What do we get out of the browser?
The desktop installed "out of browser" experience for Silverlight comes in two flavors:
Flavor 1: Sandboxed
This is not too different from the experience you get from a Silverlight application in the browser.  There are a couple bells and whistles here to support "offline" applications, as well as some notification "toast" APIs.
Flavor 2: "Trusted"
In this configuration, certain things that caused concern for phishing and spoofing (and thusly removed or requiring user opt-in from the sandbox option) have been removed in Trusted mode.
This includes allowing full access to the keyboard in full screen mode, customizing the "chrome"/window borders, reading and writing to the "My" directories (MyDocuments, MyPictures, etc)
It also allows some Windows specific APIs around allowing for COM automation.  You remember COM? Better known to the web world as ActiveX.  And while it's a very handy capability in a highly controlled environment such as an intranet, it's mostly famous for it's guilty association with malware through drive-by downloads.
Package deal trust vs. ala carte...
This is the popular strategy of passing the responsibility of risk associated with an application's installation onto the user.  Traditionally on the Windows platform, the end user is given a stern warning that they are about to give the application or component they are about to install every right, ability and privilege that he or she has.  This warning is coupled with the disclaimer that the user should only allow applications from reliable and “trusted” publishers to have this ability.
Fast forward a bit to this century, and you will find that this has been improved upon slightly on the mobile platforms in more of an “ala carte” fashion.
In mobile platforms such as Android and Windows Phone 7, the user is warned that the application may want to access certain parts of the API that may compromise their security or privacy.  This list of needed abilities is published along with the application and is listed for the user prior to the user’s consent to install the application.  Any other parts of the API not listed in this manifest of needed abilities are shut off from the application.
Granted some end users are still not going to know what they are being asked to consent to, but this model is a large improvement over the nebulous nature of the big unknown package of abilities that the user normally has to agree to.  And the users that do understand what the list is asking can make a much more informed decision whether to trust the install or not.
Silverlight 4 still uses package trust...
Going back to the roots of the way ActiveX installations warned users of potentially malicious code, Silverlight 4’s trusted applications follow this same pattern.
On the surface of this, this isn’t a bad thing as even the cross-platform specific elevated trust capabilities are still pretty restrained.  However on the Windows platform, lumping restrained abilities with the ultra powerful capability of creating COM objects basically makes trusted Silverlight 4 applications a re-skinned version of ActiveX.

For all intents and purposes, it’s basically like classifying rubber band shooters and rocket launchers as the same type of weapon.  One can sting a bit if it hits you.  The other can kill.  And even if just the rubber band is the only weapon that’s going to be used, the user has to assume that the rocket launcher is in the arsenal as well.  Suddenly office rubber band fights aren’t nearly as fun. 
Rose colored use-cases...
I know there are some out there that feel that the security concerns over COM/ActiveX are over-exaggerated.  And in many cases this is true.  I believe that COM/ActiveX is a great and powerful feature in a very controlled environment (such as a company intranet, or a user base of paying customers that are trusting you with support for the application)
However, there is some valid concern for those that think COM killed their inner child in the 90's.  Particularly to those wanting to distribute applications for general consumption by the general public over the web.
For every rose-colored and friendly usage of this ability, there are one or more equally malicious usages.  What? I can use the FileSystemObject to write files to the C: drive and the Shell Application object in the Windows Scripting Host registry writer method to add my Silverlight application to the start-up group?  That’s great and powerful and possibly even useful.
But it also affords me the ability to copy some malicious program I’ve happened to carry along in my .xap deployment to a PC and force that to start-up on boot, using nearly the exact same code.
“Well I’m not going to do that…”
Of course you’re not. Remember Spiderman? Responsible programmers realize that with great power comes great responsibility.  Responsible programmers have honor.
But even Spiderman has villains.  Those that have equal access to fantastic powers and they do not use this power for good.  They don’t care what are considered “good” practices, nor do they have the end user’s best interests at heart.
Why are vials of liquid not allowed on airplanes anymore? Because ONE person exploited security to use it as a vehicle for bringing dangerous chemicals onto the plane. And while that is an extreme analogy, the mind set behind the how trust is developed around the experience is not far off.
The heart of the issue here isn’t one of paranoia more than one of psychology.  It will take only one or two very public abuses of this capability to ruin it for the rest of us.  And the general opinion of Silverlight will be the same as ActiveX.  Ultimately it will be viewed that Microsoft has merely given the Trojans a new way to build their horse.  Notice I said “Silverlight” here and not “Trusted Silverlight 4 OOB Applications”.  Your average consumer isn’t going to bother with the differentiation.

As it is now, if you’re writing a game or something that needs full access to the keyboard in full screen mode, to gain that ability also requires you to gain the ability to create COM objects.  Or write to the “My” folder group for that matter.  It would be nice if I could absolutely guarantee to a user with absolute certainty that I am only using a subset of the powers I’m being granted.
Complaints without solution ideas are like rocking chairs…
Both give you something to do, but you never get anywhere.
So what do we do?
Honestly, I think the answer has already been implemented.  There is no reason why the same pattern utilized on the mobile platforms couldn’t also be utilized for the Desktop experience.
Furthermore, this could be added as a security patch to the existing Silverlight 4 runtime.

Consider how the team at Microsoft has addressed this for Windows Phone 7:

Something like this could be added to the manifest for desktop applications (indicating desktop specific capabilities instead of the phone ones, of course).  For backward compatibility, if capabilities are not specified, the assumption could be made that EVERY capability is needed.  Then the developer could choose to re-deploy their application with a smaller list of needed capabilities.

It would be nice as well if the “capability” in this list for COM included a group of ProgID’s the program will need and Silverlight prevents the creation of the rest.  But a way of shutting COM off/on entirely would be enough.
Both the desktop and phone implementations could benefit from a way for the developer to provide some notes at install time indicating why the various capabilities are needed.  Although the developer could provide this today on the hosting webpage itself, having it in the app provides the ability to always contain it if the application is presented to the user from some other source than the author’s website.
Final Thought: Believe it or not, “I can’t do that” is ALSO a feature
In conclusion, I want to add that the ability to say your applications “can’t do something” or “isn’t allowed to do something” is sometimes a great feature.  Particularly from an end-user support point of view.
Whether you are an ISV supporting your own product, or handing off support to some internal team inside your company’s infrastructure, the restraint of capability is a great tool for troubleshooting.  An end user can easily place blame on your application for any number of bizarre behaviors that he or she is experiencing on his or her desktop. “I think your Silverlight app is writing random files to my hard drive” is easily argued against if your application is simply not allowed the capability in the first place.
In closing, I’d like to draw attention to an item I submitted to Microsoft’s official wish-list to implement the above.  If you feel as strongly about this as I do, please consider voting it up and drawing attention to it.  Here’s the link.

Sunday, October 10, 2010

A brief history of Silverlight and a few cautions for the newbies...

This is a small history of Silverlight.  Based on my experience, it would have been nice to know what I was getting myself into before I embarked upon this technology.  Not that it's been a decision of regret.  However it wasn't nearly as smooth for me as it was implied it should have been.  Perhaps my expectations were too high or out of line, or perhaps my skills were just deficient.  At any rate, here's a brief overview and some words of wisdom for those of you new to the technology:

In the beginning... there was WPF...  
The origins of Silverlight rest on the coat-tails of a technology Microsoft invented on the Windows platform called WPF (which stands for Windows Presentation Foundation).  The basis of this technology is a mark-up language called XAML.  Basically, the idea here is that UI is expressed in an HTML/XML mashup.  The XAML reader within the WPF framework converts this tree of nodes into text, pictures, drop down lists, etc and renders them on screen as such. Basically this mark-up is a specification/recipe of how to render the visuals to your screen.  Microsoft has viewed this as a sort of Microsoft version of HTML (though some would argue it shares more resemblance to SVG).  And as such, there are strategies that allow this to exist on the web as well as in desktop applications.

The goal of this was to provide a GUI application platform alternative to the mess that is AJAX and the dinosaur that is Windows Forms.  With Apple having a very rich and friendly design environment in Cocoa, this was a huge step forward to creating a flexible platform for designing UI in Windows.  The key concept of WPF's flexibility is the notion of a "behavior" model or "non-graphic" implementation of various control elements.  From WPF's design philosophy, what a control does or can do is far more important than what it looks like.  For instance, a "Button" is basically defined as a group of behaviors and events associated with what a Button can do and how you interact with it.  You can click it, you label it with content in some form, you can hover over it, and so forth.  But whether the button is silver, round, or shaped like a cashew doesn't take away from the fact that it needs to carry one or more of those behaviors to be considered a "Button".

Microsoft provides default "skins" to the various controls (including the Button).  However, nearly every aspect of the controls beyond that can have their own custom skin provided by the developer.  Borrowing heavily from the concepts of cascading style sheets (CSS) in HTML markup, the re-skinning of the various elements can occur at various levels:  from the control's own definition, to the application (which affects every control) with similar rules of overriding the behavior.

Also like HTML, the notion of event handling is accomplished through code.  While HTML/AJAX accomplishes this with Javascript, WPF accomplishes this with code from syntaxes compatible with .Net (such as C# or VB.Net)

By the nature of using an abstract mark-up language like XAML, the implementation is very portable between the desktop and web versions.  However,  WPF has a complete dependency on the .Net framework.  Which (unless you count the Mono project) is a technology exclusive to the Windows OS.  Consequently, WPF has just been viewed as a fancier version of ActiveX by most.  And just like ActiveX, you're not going to see WPF content on a Mac or Linux.

Enter WPF/E Silverlight
With the proof of concept for deploying WPF content to a browser essentially proven, the next step was to see if this could be forked off into a solution that was not only cross-browser compatible, but cross-platform. So, the first prototype of this was called WPF/E (WPF/Everywhere).  "Everywhere" at the time was considered the Mac and Windows platform.

Basically the concepts are and were the same as WPF.  UI is expressed in XAML mark-up (with WPF XAML mark-up nearly 100% compatible with WPF/E's version).  It was given it's own version/runtime of the .Net framework (which eliminated a lot of implementation redundancy and Windows specific APIs).  And as a result, given it's own development environment and deployment strategy in the form of a browser plug-in not too dissimilar to Adobe's Flash.

At release, WPF/E was dropped in favor of the term coined today:  "Silverlight".  Through a collaborative effort between Novell and Microsoft, an open source free software foundation-ish implementation has been created called Moonlight.  This is intended to target the Linux platforms.

Development Gotcha's...
This is where all the marketing and hype get put into perspective.  Before you get working on Silverlight, there are some things and certain mindsets you need to get accustomed to.  I know that if I had this knowledge, it would have made things a whole lot less painful.

  1. Silverlight is it's own thing.
    One of the most common misconceptions about Silverlight is that it is part of the standard .Net ecosystem.  This is simply not true. (Or not entirely true) While it certainly shares the same design and development philosophies and IDE, the only thing it really has in common is the syntax's supported by it.  Assemblies (DLLs) compiled in the standard .Net framework are not designed to be compatible in Silverlight, nor are Silverlight assemblies designed for compatibility with standard .Net.  Outside of certain unit test hacks, Visual Studio will generally forbid you from attempting to cross pollinate like this.

    Remember that Silverlight's .Net runtime is a much smaller subset of the "real" .Net framework, with pattern redundancies reduced and Windows-specific APIs removed or abstracted to fit a context suitable for cross-platform implementations.  As of this writing, both Windows/.Net and Silverlight contain APIs specific to their deployment platforms, which makes forcing this compatibility even more of a challenge.

    As long as you remember that you're basically targeting another framework that simply has C# in common with it and a few libraries that just happen to look like standard .Net libraries, you're on the right track.

    I should note that Silverlight 4.0 has tried to address some of this weirdness by allowing some .Net class libraries to exist in Silverlight 4.  However, this only works if your .Net class library's external library references are limited to a few common references between .Net and Silverlight's equivalent library sets.  Basically, the purpose of sharing assemblies here are for lightweight value objects and common algorithms that aren't doing a whole lot and don't require a lot of dependencies on a lot of .Net libraries on either side of the coin.

  2. Silverlight is designed for the browser first and foremost.
    Since version 3 of Silverlight, the concept of an "out of browser" application has been introduced.  However, it should be noted that (at least on the desktop versions of Silverlight), even out of browser applications need to originate from a web-page.  In these scenarios, your webpage acts as the "setup.exe" boot strapper to the installation process.  Users can right click and choose to install the application from the Silverlight plug-in directly.  Or, if you want to build a mandatory or custom install experience, there are APIs built into the Silverlight-specific libraries to handle that.  In that scenario, your application contains the installer logic in addition to it's primary functions.  This is significantly different than the installer deployment packages created with the .Net framework such as msi's or ClickOnce.

    As Silverlight is designed for the browser, communications with the hosting server (or any other web service) are only allowed asynchronously.  This is intended to prevent a Silverlight application from locking up a browser while it waits for results.  Remember that Silverlight's access to the outside world rests on what the browser allows and provides.  This interface is a published standard, and how it's implemented from browser to browser is largely up to the browser's development team.  This asynchronous way of doing things is to ensure a consistent experience for service calls.  It should also be noted that this communication occurs only when Silverlight's engine has control.

    A side effect of this is that you generally
     want UI elements to change based on what you get back from a service call.  You have to do this in the call-back event handler you specify on the web service call.  This essentially makes you split your UI logic up amongst one or more methods that have little knowledge of one another.  For example, a click event on a button could trigger a web service call.  But you can't fill in text boxes based on the results of that event until the web service's asynchronous callback has been fired.

  3. Rendering occurs as RETAINED (or once per frame)
    When dealing with graphics, and especially when targetting OpenGL or DirectX, it's important to understand the difference between rendering modes.  There are basically two main flavors:  Immediate Mode and Retained Mode.

    Immediate mode rendering is similar to the way you're doing in Windows Forms.  Basically, every instruction you give that modifies the display in some way occurs IMMEDIATELY.  Traditionally, what this has meant in the Windows Forms realm is that you introduce an inefficient effect called "over draw".  Basically what this means is, your program can end up triggering events and processes that force the display to repeated update and display portions of the screen.  Sometimes this is desirable.  In other cases you end up re-painting over the same part of the screen over and over again until it resembles the final state that the user see's.  Often times this generates artifacts on the screen, or simply introduces lag time and unresponsiveness until all of those unnecessary draw operations have completed.

    In Silverlight, nothing is rendered until control is given back to the Silverlight engine.  This is called "Retained" mode.  The concept here is that the screen's display element hierarchy is scanned once for changes and rendered once to reflect those changes.  

    What this means is that setting a checkbox control to checked in an event handler will not actually perform anything on the visual until your call stack has emptied out and control returns to the Silverlight engine.  Setting properties that affect visuals at this point are merely providing a specification to the renderer when it scans through the objects that make up your display.  This makes for efficient rendering, but it doesn't give you accurate access to any properties that are changed as the result of a render.

    So in a way, Silverlight has a rendering lifecycle closer to ASP.Net than Windows Forms.  Except the lifecycle completes several times a second and doesn't require any communication back to the server to figure out what the page looks like.

  4. Silverlight IS the application.  Your program is merely a parameter passed to it.
    Okay.. I know that sounds a little harsh.  But consider that none of the heavy system level lifting ever occurs until the Silverlight runtime retains control (i.e. your program's call-stack empties itself out).  This is true of rendering, and also true of any service calls out to the internet or hosting server.  

    With very few exceptions (pardon the pun as that's one of the cases), methods, classes and properties that interact directly with the Silverlight runtime act like a checklist for the engine to follow rather than performing any particular action directly.  Calling methods to perform a web service simply queues up the request.  That's right. It's true!  If you call a web service that only takes a second and then force a wait delay in your code for five seconds, you will find that the request never even fires until your method returns control back to Silverlight.  So if you prefer synchronous calls, you're out of luck.  As I just mentioned, you can't even add delays to block code while you're waiting for the call back.

    Also, as mentioned above in #3, the UI renders in a retained rendering pattern, and basically follows this same process for the visuals.
So if you are embarking on Silverlight for the first time, beware of these items. Peripheral understanding of how the runtime operates helps quite a bit before you waste time trying to implement patterns or APIs that fight the way Silverlight processes things.  Silverlight will always win in those fights, so it's good to know how to develop around the way the runtime prefers to execute.

Back to the blog...

Well.. it has been a crazy couple of months.  The unfortunate realities of work/life balance and motivation has not been conducive to blogging.

However, that doesn't mean I've not been causing trouble elsewhere... which I will chronicle here a bit in the entries that follow.  Stay tuned!