Sunday, December 5, 2010

Silverlight 5!

With great fanfare yesterday, a PR/Developer event called Silverlight Firestarter was unleashed upon the world.

Silverlight 5!

Silverlight 5 was announced, and is very good news for those that want to develop enhanced media experiences.  It's also good news for those developing line of business applications.  Boasting over 40 new features. John Papa has detailed many of them on his blog.  I'll touch on just a few of them here...  So grab a soda, ease into your comfortable chair, and lets have a look, shall we?


Media Experiences
So.. let's get the "media experiences" out of the way:

  • Hardware Decode and presentation of H.264 improve performance for lower-power devices to render high-definition video using GPU support.
  • TrickPlay allows video to be played at different speeds and supports fast-forward and rewind. At up to twice the speed, audio pitch correction allows users to watch videos while preserving a normal audio pitch.
  • Improved power awareness prevents the screen saver from being shown while watching video and allows the computer to sleep when video is not active.
  • Remote-control support allows users to control media playback.
  • Digital rights management advancements allow seamless switching between DRM media sources.

In short, it's the obligatory "this is what Netflix wanted us to put in or risk a move to Flash" portion of the release.  I know that might sound a little harsh, as I'm sure there are other media rich sites out there that are using the playback capabilities of Silverlight.  Outside of Microsoft dog-fooding and Netflix, I can't think of any others off the top of my head.  A bit of a shame though, as these are some pretty powerful video features.  Just a very hard sell against similar components of the cross-platform focussed Flash players.

Personally, I'd like to see someone make a pretty HD cloud-based Dragon's Lair clone that will work on a Netbook without draining your battery after one play-through.  Are you listening Digital Leisure? I think Azure is the one platform you don't have a version of Dragon's Lair for yet. What are you waiting for?


Improved Text Presentation...

  • Multicolumn text and linked text container allow text to flow around other elements.
  • Tracking/leading set precisely how far apart each character is for full creative control.
  • Text clarity is improved with Pixel Snapping.
  • Text layout performance is significantly improved.
  • OpenType support has been enhanced.
  • Support for Postscript vector printing.
So what does this feature set mean?  Maybe PDF support (Or PDF enabling technology. That last bullet point provides a means for doing a sort of WYSIWYG ability)?  Or perhaps it's a precursor to a Silverlight version of the SQL Server Reporting Services report viewer component (which would be no less than awesome).   Or maybe it's a way to allow Silverlight as a deployment platform option for e-book reader developers.  And especially if these features find their way to Windows Phone 7, it would be an easy sell to encourage Barnes and Noble to target Silverlight as their deployment platform for Windows, Mac and WP7 for their Nook e-reader.

Business Applications...

  • Model View ViewModel (popularly known as MVVM) pattern improvements.

Personally, I've had a bit of a love-hate relationship with the MVVM pattern in the XAML/WPF world.  Specifically, I've not been a fan of the lack of type-safe compile time warnings when utilizing it.  The XAML approach to MVVM still relies heavily on "reflective" behavior, which means a typo in my field binding is going to more than likely yield a "successful failure".  (i.e. a non-crashing bug that just renders ugly/incorrect  results).  Unless you're a stickler for detail, and an avid tester, you're not always going to catch all of those bugs, especially if changes to a ViewModel are not carefully propagated to it's dependencies.

Well it appears that this is a pain point was a noticeable one at Microsoft.  Silverlight 5 now allows setting break points in the XAML data-binding structures to at least see why binding failures are occurring.  It's not a perfect solution, but it's a good compromise without neutering the power given to the reflective way that MVVM operates on today.
  • Support for 64-bit operating systems.
Why is 64-bit important?  Some other bloggers have their opinions as to why.  I believe the key reason for this is related to the final bullet point in the aforementioned link.  "Ability for Silverlight to work together with other 64-bit applications together"

Specifically, the primary motivation for this is the continued Active-X-like features (I have blogged about this direction previously).  Native/unmanaged code interoperability is a tricky thing in mixed environments.  When you are running an x64 version of Windows Vista or 7, you're essentially running two operating systems at the same time.  A 64-bit one, and a 32-bit one.  These two worlds are normally invisible to the end-user for homogeneous applications living on one-side or the other (such as running 32-bit Word alongside 64-bit Internet explorer -- which is a good thing).  And the ability to do this is a fundamental reason why AMD won the 64-bit processor war over the Itanium chipset from Intel (which more or less killed 32-bit compatibility at the binary level)

But when developers have to mix components from both worlds into a single application, things get a little trickier.  Especially if you're a 32-bit application trying to get 64-bit components to execute.  As most Windows installations today are leaning toward x64 installs, having a 64-bit version of Silverlight leaves fewer opportunities for things to go wrong when the COM interoperability aspects are utilized.

And speaking of COM interoperability, it looks like the out-of-browser context gained the ability to P/Invoke unmanaged code.  This means code can be accessed now that doesn't have a COM binding.  This presents opportunity for the creation of Silverlight wrappers for certain binaries.  For instance, future versions of DirectX could theoretically ship with Silverlight SDKs to get to XBox Controllers or Kinect or whatever if you wanted to provide that functionality to Windows specific applications.

It also looks like a mash-up class of applications that sit half way between out of browser and in browser (in terms of security and application permissions) has been put into play here as well.

3D Support! 
Quite possibly the most exciting feature about this release of Silverlight is it's introduction of 3D graphics support.

If you watch Scott Guthrie's keynote (around the 51:00 mark), there's a very impressive "medical" demo detailing a very scary-accurate 3D model of Scott Guthrie himself.  



There was an interesting "layering" feature demonstrated that allowed the presenter to control the opacity of various groups of polygons on Virtual Gu.  The effect was enough to make a TSA body scanning agent envious.


Neat stuff on the surface and it's easy to get excited about features like this.  However, given that Silverlight today now touches 3 specific platforms (not counting Symbian, which is WAY behind), what do the APIs look like between Windows, Mac and Windows Phone 7?

It's probably safe to say that the Windows and Mac APIs look alike.  But Windows Phone 7 already has a 3D API in it's Silverlight interoperability with the XNA framework.

WPF (which seems to be getting phased out more and more as Silverlight gains better display features), has it's version of a 3D API in WPF-3D.  It seems natural that the new 3D capabilities would look similar to either XNA or WPF-3D.

From a portability standpoint, it would be best if it were a convergence of XNA and Silverlight.  This would allow applications (in a slight twist of fate) to port from Windows Phone 7 back to the desktop version of Silverlight.  This would allow developers a path for 3D games to the Mac without splitting their efforts too much.  And as Apple now has an app store, this could be a way of monetizing Silverlight on the Mac platform (provided Apple doesn't have certain regulations in place similar to their iOS line that prevent it).  It would also present opportunities for Silverlight applications to communicate with XBox Live.  How cool would it be to get achievements on a game you're playing on your XBox, Windows Phone, Windows AND Mac? 

I tweeted a question related to this to Pete Brown, Microsoft community program manager for Silverlight, and author of the excellent book "Silverlight In Action":

To which he replied:

Now to be fair, Silverlight 5 is in it's early stages (or at least early enough to not give us a preview binary).  And Pete's answer seems speculative more than definitive, so what he's said here may not be correct or subject to change.  But I think it's a missed opportunity if the API set for 3D is inconsistent across the 3 Silverlight platforms that matter most.  Given the disappointing lack of interest  Microsoft has shown recently to attempt to get Silverlight on more platforms, an effort toward the "code once, run all" originally promised by the framework would be greatly appreciated for the few platforms they DO support.

Silverlight 5 seems to be on track to be a minor leap in some areas and major exciting (and maybe disruptive)  leaps in others.  What was shown was impressive, but (as I mentioned here and others have mentioned here and here), Silverlight's biggest sought after feature by developers continues to be the one they seem the least interested in pursuing:



Saturday, November 6, 2010

The Gu to the rescue..

Well mostly.

I think much of the already shaky acceptance of Silverlight won't be solved by Mr. Guthrie's post (I'm talking globally here.  Let's be realistic, it's not exactly synonymous with Flash in terms of wide spread acceptance or even general public knowledge.  If I had a dime for every post I've seen that says "What's Silverlight?  I've avoided installing it because I don't know what it is..."...)


Mr. Guthrie did a good thing by attempting to smooth all this over. Given that there's a Chief Architect position open at Microsoft right now, it was probably a VERY good career move to do so.  Mr. Guthrie is one of the few individuals at Microsoft upper management that I know of that has commanded the respect and admiration of the Microsoft development community out of pure honesty and sincerity.  Heck, I know a couple of Microsoft haters that have nothing but good things to say about him.  Kudos Mr. Guthrie.  While I don't think this is a 100% improvement over Bob's version, nor is it exactly what all the developers wanted to hear, I'm betting more will certainly like your take on it by quite a bit.


I'm actually a bit surprised at the number of developers that were personally affected by BobMu's ZDNet interview and subsequent follow up on the Silverlight Team blog. There are several who have claimed that the fuster-cluck and mishandling of the Silverlight "strategy shift" have alienated projects they had championed.  Clients, who were once on board with it suddenly are not.

I can luckily say that the Silverlight applications I've championed and been involved with at work have had a very small audience (speaking in the global terms I spoke of above).  In fact, I green-lit Silverlight as the framework for our next application.  But the scope of usage is very well defined (Windows users only, connected to the intranet).  The fact it will probably run on a Mac too is just an irrelevant bonus. From the sounds of the Gu clarification of Mu clarification of the Mu interview, ours is a relatively safe use case (though to be fair, i don't think that was unclear in BobMu's clarification or his original interview).

However the reason for doing this wasn't so much the superior technology.  It wasn't even really the development tools.  We could easily accomplish the same thing with Winform or WPF.  It has a more to do with leveraging the reusable components we already had and how much easier/stable the deployment is strategy is in Silverlight.  If we had not already had a sizable investment in "ramp  up", and weren't already familiar with nuances, it would have been an extremely tough sell to management, let alone the rest of the team.

I still don't think those at Microsoft (including Scott Guthrie) completely understand the biggest complaint in all of this.  I think in the end, a good portion of the Silverlight community wanted a better Flash/Air, including the ability to run it on most platforms (or at the very least, as many as Flash can run on plus a couple more).  The only proof they need is from Microsoft's own feature request site (as of this writing, 5,417 votes and easily the top requested feature by over 1,500 votes)

Somehow, I doubt the expectation from the development community was that it would be on every product from your PC to your toaster.  I think the expectation was at LEAST the same platforms as Flash.  Or in other words, the top 8 most popular and feasible ones.  Heck, Microsoft owns at least 3 or 4 of those.  I think most developers would even be fine with the idea of it being an application framework with binary compatibility only at design time (which would make iOS deployment a real possibility).

A few weeks back, I wrote an entry on my predictions for PDC.  And while I was correct on a couple of minor items, I was WAY off in regard to the Silverlight strategy.  

In that entry, I noted that there is known evidence of Silverlight running on Moblin (and presumably Meego).  I was also pretty sure we would see Silverlight applications on the Xbox as well.  Especially since there is a Silverlight player on the Xbox 360 TODAY that developers outside of Microsoft do not have access to. 

Not to mention, they have a great symbiosis with the Mono team at Novell.  Given the proper authority, resources, and patent safety (beyond the Office leverage Novell already has), I suspect that team would be a great work horse to implement Silverlight-accurate Moonlight versions on other platforms while the Silverlight home team drives the core version forward.

So, I believe the cross platform story is attainable, and I suspect there is even a couple ports of it that are in 80-95 percentile area of completion.  But politically or otherwise, despite the fact it's something Microsoft's developer customers want (the top requested feature, to be exact), it's essentially over.

Of course, you never know what they are planning.  Optimistically, perhaps they are saving a big surprise for MIX 2011.  If that's the case, I think it would be a good idea to play one of those cards now (say the XBox one, if it exists).  And they best be prepared for the usual questions around Silverlight for Android (at the very least).  To be honest with you, I suspect a solution to that one platform would be enough to win everything back.

Saturday, October 30, 2010

Microsoft Kombat!!!

 
microsoftkombat
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”.


Moonlight
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.




Politics…
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:
PhoneCaps

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!

Sunday, July 18, 2010

Cross Plat-formalities

I recently enjoyed an article written by Microsoft employee Justin Angel on the cross platform nature of Silverlight.

I have to admit.. I like Silverlight a lot.  Or at least I think I do.  I like the idea of what I think Silverlight is... (rest assured I will elaborate about that on a separate date).

But something struck me in Justin's article:

"A common trend amongst all the differences we’ve surveyed in this article is that they’re all to do with deep Operating System Integration or Browser Integration.  These are either issues with the operating system or the browser itself. 
Remember that .Net at it’s core is just a framework abstraction on top of the O/S. 
And as anyone who’s ever written a framework knows, some differences cannot be abstracted away. "


I can make no claim of writing a framework the magnitude of .Net, and I am sure there are a number of show stoppers regarding what is exposed to Silverlight outside of Microsoft's home turf of the Windows environment.

But, I do have some experience with cross platform development, and I would have to say that I ran into these same issues under Python and Java.

So what's my boggle?

In those situations, I certainly had to write platform specific code/factories and execute their strategies based on where the application was running.  However, I wrote this code as a shared middleware layer.  All of my client application code called this middleware layer without worrying about the platform it was sitting on, and the middleware handled the appropriate funneling of platform specific code.

If that isn't abstraction, I don't know what is.  So, if I can do this, why can't Silverlight, Python or Java?  Justin's assertion that "some differences can't be abstracted away" is true in a "I can right click and you can't" or a "I have to touch/tilt and you have a keyboard" type of way... But what about those things below the surface of user interfaces and interaction?

I think the fuzzy truth here is one of politics and avoidance of religious debate.  With my framework, I had the luxury of making a decision about how it should behave.  And I also knew that I likely wouldn't have to worry about platforms outside of Windows and Posix flavors.


Often times, OS's have functions that are similar in feature, but behave slightly differently.  For example, in Linux, if you attempt to move a file across a hard drive boundary, the operating system would bark at you.  It's not legal because a "move" in Linux implies that you're merely changing it's pointer in the file look-up table.  Windows is another story, it will change the pointer if it's on the same drive, and do a copy/delete operation if it's not.


In my framework, I had a version of "move" called by all of my client code that made this operation behave like Windows across the board.  Clearly, I didn't have a horde of ravenous Linux fanboys to worry about here saying that I was doing it "wrong", or I was trying to mislead anyone into believing Redhat did that operation some other way.

But, you can imagine the type of drama Microsoft would have to deal with if they took it upon themselves to say that some operations on the Mac should be changed to act more like a Windows box?  Perhaps the Mono team is running into similar challenges with Moonlight.

So.. I would revise Justin's statement slightly to say that "aside from extreme, unresolvable cases, some differences can't be abstracted away without introducing bias toward one platform"

In a perfect world, I'd like to see cross platform frameworks take the best features of one side or the other.  Like a stew of the best functions of each platform they target.  Of course, this will never happen, and in some cases isn't always feasible (as Justin's article indicates, there are some Windows OS concepts that simply don't exist on OSX).  And it puts the burden of those decisions on the cross-platform framework developers.  Probably not a place they would prefer to be.

In closing, I'd like to add another Option to Justin's "What should developers do?"

Option 4 - Know what you want to target, and implement your own abstractions where you can.

The powers behind Silverlight, Java, Python, etc..  They really can't make these command decisions without causing turmoil (whether it's the burden of additional testing around overriding native behavior of a platform, or the danger of a lynching from fans of a particular OS).  But nothing stops you from doing it if you own your application.  If you want Mac and Windows to both return "INFINITY", thats a trivial abstraction you can do to reduce the burden of code branching in your client code.

Want drag and drop to work without thinking about it? If you're using ASP.Net, you can easily make a UserControl composed of the silverlight plug-in and the necessary javascript events and code if the client browser is running on Safari.

Or... if you don't like such hackery, KNOW what you want to target, and go out of your way to avoid the APIs where things are known to behave differently or flaky.

Cross platform development is tricky business and requires a high level view of the app's expectations across all the places it's going to run.  But there are a lot of software developers out there that are doing it.  Particularly in the game development realm.

Next time you go to the store, see how many of the same titles exist between Playstation 3 and XBox, and see how many common middleware frameworks are credited on the back of the box.  (Havok, Bink Video, fMod, etc) This is a prime example of Option 4 in action.

In the end, it all has to behave the same, so the differences are formalities.  Or as I like to put it... Cross Plat-formalities...

About Me: The Director's cut...

Howdy folks...

I'm a little new to the whole blogging thing.  Traditionally, I have not shared my knowledge and life outside of those I directly communicate with.  But seeing as I am a developer in 2010 (and hopefully beyond), it's high time I live in the now and start spouting off at the virtual mouth like every other dude that's been doing this for as long as I have.  I will say that I can't take credit for this decision.  I took some prodding from a couple of people (that's right.. looking at YOU, Tami and Scott).  I guess I've managed to convince (or fooled them) into thinking I know what I'm talking about on some subjects.

Anyway.. since I am so new to blogging (and Blogger in particular), I managed to blow past the amount of space allowed for my bio.  And since I never tire of patting myself on the back, the following is the director's cut of my original bio:


I am a software developer, and have been able to develop applications for what is now a majority of my life.  


I am currently employed by a significant player in the building and contracting industry to provide a few highly integrative applications for estimating, reporting and managing projects.  Odds are, if you live in the southwest, you may have stepped foot in or heard of at least one of those building projects that the applications my team has written has helped manage.


Over the course of my life and career, I've developed on a multitude of platforms.  I have written for the Vic 20/C-64, Amiga, Apple II and other systems of that era as well as modern platforms such as Windows, several flavors of Posix and the web. I have dabbled a bit on Mac and mobile platforms such as Windows Mobile, Windows Phone 7, and Android.  I have coded in more programming languages  than I can count on one hand (maybe two if you count some lesser known syntax).


Professionally, I've designed the architecture for and written a variety of applications and systems.  I've written real estate search engines and credit card processors. And I've written applications that estimate a cost of a building to actually displaying and reporting information on that building in a naviagable 3-dimensional model. 


My spare time is a commodity.  But when I have it, I enjoy outlets of creativity such as art, movies, music, games (video and otherwise), and cooking.  I especially enjoy those things any time I can share the experiences with my extremely supportive and close family or if I can combine the creativity with my passion for coding. 

I'm hoping I can add blogging to that list.


There you have it.  And this is the end of my first (albeit pretentious) blog entry.  I promise that at least one of the ones that follow will be far more worthy of your time and readership... or your money back!

Best Regards,
Dan