Future of XBAP

Back at Mix'07 when I first heard about XBAP I thought it could prove very handy in coming years and I was expecting to see many applications in coming months build on XBAP, but the last time I had a healthy discussion about XBAP developers was in Nov'07, well that was about 2 months ago, as it happens I had that discussion just before we heard about Silverlight 2.0, so why is no one interested in XBAP anymore?

XBAP only came to existence because Silverlight (at the time 1.1 Alpha)  didn't provide the basic user controls, binding options, and many restrictions on Silverlight usage with assets and/or web services, Silverlight applications mostly lack the infrastructure to use .NET framework so the only option was XBAP.

XBAP was simple and neat idea build on WPF but when it come to universality, it lacked cross platform compatibility over Mac/Linux. But when Silverlight 2.0 was announced with user controls, binding, grids and to lift many restrictions like cross domain calls, and providing support for web services methods like SOAP/REST, the idea of developing XBAP applications just began to fade away.

So with Silverlight 2.0 Beta 1 to be released in next 6 weeks what is the future of XBAP? Its not a simple question and personally I am a bit optimist and would love to say good byes to XBAP but ever since Mix 07 Microsoft has disappointed me again and again with Silverlight, I am hoping the Mix 08 will change all that, but I am sure that after a few months after Silverlight 2.0 is released developers might again start to talk about XBAP but this time for some other features that Silverlight might lack mostly with 3D or networking supports like sockets or VOIP.

After Mix08 and Silverlight 2.0 Beta 1 is released I'll try to post the features that Silverlight 2.0 lacks and in what situations would XBAP could be used, if at all. Please stay tuned.

Silverlight 2.0 - Unicode and Full Font Support

In Silverlight 1.1 Alpha Microsoft included only English Language support  for text and there are only 9 fonts available, 8 normal text fonts and a symbol font without any Unicode support.

Additional font support is available as downloader objects, the font not specified by default in Silverlight applications should be downloaded in cache along with other assets.

The reason for this is that Silverlight 1.1 Alpha applications run in a sandbox within a browser, the font directory is a systems directory and the security restrictions restricts the access of the system directory to the application. Microsoft could have included more fonts for the Silverlight plug-in but to reduce the size of Silverlight plug-in, it was restricted to total of 9 fonts.

However, because of this reason, there is no Unicode support for other languages, if a desired Unicode is required the font should be downloaded as downloader object into the project solution. For complex scripts like Chinese, Japanese, Arabic or Hindi the font size could be anywhere between 6 MB to 12 MB, resulting in the client required to download the font again, where it normally is already available at client's system directory.

Microsoft,  although not officially commented to do "something about it" in Silverlight 2.0 beta, as far as I am concerned it is an entirely essential to include the support. But how Microsoft is going to allow access over cross platform to a system directory from a sandbox,  is yet to be seen, this could easily end up catastrophic and could leak security flaws.

My prediction is that Microsoft is going to follow the same path as Silverlight 1.1 Alpha applications that is loading non available fonts as downloader objects, but at the same time they are going to allow Silverlight plug-in to check the systems directory for the availably of the font and if the font is available then make a copy of the font in the working cache directory for easy access, if no Font is found then it can download the font as a downloader object.

This scenario could solve  the problem not just for Unicode support but makes any Open Type (otf) or True Type (ttf) fonts to be available to the user.

I would rate this feature as a must and Microsoft also realised the issue so do expect to see it in Silverlight 2.0 Beta in March 2008.

Apart from that, I would also like to see the Silverlight SDK engine to allow all fonts available at design time, by automatically including the font in the project solution, not as an embedded resource, but as resource asset

Overall, I hope font support in Silverlight 2.0 will get better but how better depends on how serious Microsoft is going to take this issue. So I would rate this font feature expectancy as 5/5

RichTextBox makes Rich RIA

Rich Text Box, probability the one feature that could change the face of Internet applications for good, that would take Silverlight platform to the extreme, both in terms of usability and adoption, this might give Adobe nightmare, and one that every HTML developer looking forward to.

If RichTextBox is made available in Silverlight 2.0, with binding capability with XML, many developers might pay their last respects to HTML and CSS, and server pages (PHP, ASPX, JSP) will be used to generate dynamic XAML instead of HTML. AJAX would be replaced with Silverlight, giving developers easy to manage extensions UI.

The framework for RichTextBox adoption is already in place, developers argue that this type of adoption will restrict the search bolts to search for data inside a Silverlight control, but RSS and ATOM feeds might come to rescue.

RichTextBox is already available in WPF application and the adopted in many applications like New York Times Reader, but its availably in Silverlight is still unknown, officially Microsoft hasn't spoken about this feature, and it isn't included in Silverlight 2.0 roadmap, the probability of seeing RichTextBox in Silverlight 2.0 is slim but the probability of such a feature is still there.

Rating:

FEATURE: 4.9/5

EXPECTANCY: 2/5

CSS in Silverlight? Oh Yeah! Even Better? Hell Yeah!

CSS existence is quite ancient but the true potential of CSS was realised only for parsing XML elements. Ok we already know that and also that XAML is XML based or atleast the inspiration/syntax is, does it mean we can expect CSS type styling in XAML, if it can be used in XAML does it mean we can use it in Silverlight 2.0 applications?

Too many questions but a simple answer, CSS is thing of the past  with many issues like incompatible browsers, hard to retrofit, hard to learn, time consuming, pain staking need I say more? Next generation technology requires next generation style sheet format,  so please welcome XAML Resources.

XAML What?

You heard - XAML resources, providing style sheets in XAML format as simple as that. Wait a minute, does it mean we can design our own custom buttons or controls from a graphic designer in one XAML and use is across the applications?

Yes, how about an example?

<Page.Resources>
  <SolidColorBrush x:Key="MyBrush" Color="Gold"/>
  <Style TargetType="Border" x:Key="PageBackground">
    <Setter Property="Background" Value="Blue"/>
  </Style>

  ...

</Page.Resources>
<StackPanel>
  <Border Style="{StaticResource PageBackground}">

  ...
  </Border>
</StackPanel>

Is that it? What? How? When?

Yes that is it, want to learn How? Already in use in WPF applications. Silverlight 2.0 Beta supports it? Not sure ask Microsoft. Can we expect it? Yes we can, I give 4.7/5 for expectancy. 

Please leave your comments.

Issues - Silverlight 2.0 Backward compatibility with Silverlight 1.1 Applications.

I wonder how many times Microsoft is going to disappoint the developers community or early adopters of Silverlight.

When Microsoft first announced the technology I had mixed feelings about Silverlight, and I went on to even say "Silverlight, Why should I bother?" my problem was with Silverlight 1.1 Alpha, this is what I had to say then.

"The point is, yes, ideally Silverlight is a great concept, and it would revolutionise the way web looks, feels and works and it can even compete with Adobe Flash and put Adobe out of business even if you compromise Microsoft's poor graphic designers .If and only if Microsoft can actually finish what they started...

Don't take me wrong, I am totally happy with the work folks at Microsoft are doing and the concept of Silverlight, I just don't see the point of launching alpha version of a software that have a very long way to go and every one know what is missing. In days to come you will see Silverlight applications here and there, mostly in video streaming and few other games but the total power of Silverlight can only come to surface when Silverlight can support import of vector graphics from other formats, full security features (especially SSL), user controls (the basic controls will do), and finally database objects. "

And after seven months, nothing has changed, so I was right, they wanted MIX'07 to be a success and it pushed them to announce Silverlight 1.1. And they left early adopters waiting in anticipation for months on end then came the announcement by ScoutGu about renaming Silverlight 1.1 to Silverlight 2.0 and Beta version in MIX'08, now don't get me wrong but that is almost a year. Microsoft is never supportive of the developers, they tend to keep big secrets many suspected (including myself) that Silverlight 1.1 might take a long time to develop, but I could never have imagined that you will go to MIX'08 to announce Beta. I think Microsoft should atleast release Silverlight 2.0 Alpha by Christmas, they own these early adaptors something. I was hoping they might release Silverlight 2.0 Alpha December Preview, but it shattered with Mono's Moonlight announcement, the latest Moonlight release (1.2.6) supports Silverlight 1.1 applications, if we were getting December preview of Silverlight 2.0 then Moonlight won't have went to the trouble of release a version to support Silverlight 1.1. So that is it, we can't get to see Silverlight 2.0 till after MIX'08.

If you thought that was enough, the worst was yet to come, Silverlight 2.0's backward compatibility with Silverlight 1.1 applications was nagging me ever since Silverlight 2.0 announcement, when Tim Sneath posted Why Can't I "Go Live" with Silverlight 1.1 Alpha? on his blog and mentioned,

Silverlight 1.1 (now known as 2.0) is not ready for "Go Live" usage at this stage, and the EULA explicitly prohibits deployment in production sites.

I took the opportunity to ask him about Silverlight 2.0 backward compatibility with Silverlight 1.1  I wasn't really expecting Tim to answer as they are always secretive about future releases, but when Tim replied, the answer wasn't to my liking,

Imran, there are substantial breaking changes between the 1.1 alpha and what will become the final 2.0 release - we don't claim to be backward compatible with 1.1 alpha. However, 2.0 _is_ fully backward-compatible with 1.0 applications.

Now that is devastating, not for Microsoft but for the early adopters of the technology, Microsoft still benefited by the buzz and hype surrounding the Flash Vs Silverlight argument which only early adopters made possible, now if Silverlight 2.0 is going to be so different to Silverlight 1.1 to the extend that they can't even be compatible, then the question is what have the early adaptors of Silverlight 1.1 Alpha archived since Silverlight 1.1 was announced?

It was not about poor implementation or planning for Silverlight on Microsoft's part, every one knew what was missing, everyone know what was required, but still Microsoft went on to announce Silverlight 1.1 in MIX'07 just to create the hype in the developer community and provide the exclusive marketing with the developers.

If it was not for the early adopters of Silverlight 1.1, Silverlight 1.0 community won't have been where it is now and now we .NET developers have to start again in March after MIX'08.

I hope history doesn't repeat itself.

Silverlight Deployment - Easy or Fussy?

Structure of Silverlight allows designers and developers to work in different environments and synchronise their work simultaneously, but the same features come back to hound the deployment process.

Deployment of Silverlight applications could have been made easy, Silverlight uses .NET Framework 3.5 for development and System.IO.Packaging Namespace already available in .NET 3.0 could have been used to help deploy Silverlight applications. 

Microsoft uses this same package architecture in XPS document specification, if Silverlight uses the same method not just the deployment will be easy but also the downloading of the Silverlight application inside a browser will be easy using Downloader Object. The application will download faster, firstly because of the compression, and because there will only be a single file to download reducing multiple server requests.  And you can have centralised control of Silverlight objects.

I am really struggling to find the reasons why Silverlight shouldn't implement this option for Silverlight.

I would rate this feature 3.5/5