I have done some thinking about some of the popular applications that I write.
A large percentage of applications are web applications that try to accomplish a lot of complex tasks.
Think about it; the CRM systems, the ERP systems and the CMS systems. Why are they all web based? At the end of the day, a web browser with a zero installation footprint is the best (and safest) option and preferred by both home users and business users.
The problem is that web applications are slower and much dumber than smart client applications leading to a lot of unnecessary traffic being sent to the client side.
Until the release of Silverlight, there was no real of way of having the reach of a web application coupled with the smarts of a .. well smart client.
I am thinking of attempting to re-engineer the ASP.Net starter kits into Silverlight, when I get some time. I know Rocky was thinking of creating a CSLA-Lite version to run on Silverlight and I would definitely prefer using it if it were available. What would be great is if a compression extender for the WCF portal were built into the framework, both in the light and full versions. That would make such awesome applications. Imagine the footprint a Silverlight CRM/CMS/ERP system would have because:
- firstly there would less traffic to send to the client side after the initial application gets cached. That is moving from stateless to partially statefull applications, so less HTTP traffic.
- secondly, compression of this traffic from the server side and uncompression on the client side (at the expense of CPU cylces) would be just awesome. I reckon, you could reach even dialup customers with much more performant applications! A bigger reach plus faster response time = more customers!
I know Rocky has a full time job and the compression bit may be asking a lot.
In any case, there is a sample provided with the WCF samples that shows how easy it is to add compression. The only thing I am not sure of, is whether the DLR will support WCF compression/ecompression calls.. pretty sure it would.
Would love to hear your comments on this.
Shailen Sukul
Software Architect/Developer
Ashlen Consulting Services
Generally speaking, Silverlight uses AJAX-style callbacks to the server, and so your best bet is probably to use HTTP compression just like you would with any web site where that provides value.
The data portal is one component that almost certainly won't translate to CSLA Light. The very nature of Silverlight, from an architectural perspective, means that you should treat the client application (Silverlight) as being separate from the server application (your services). Only messages should flow between applications (never objects), which rules out the use of mobile objects - from an architectural perspective.
Additionally there are technical issues, like the lack of a "real" serializer in Silverlight. No BinaryFormatter or NetDataContractSerializer means no way to do a clone of an object graph - locally or across the network. That rules out a data portal, and also a simple Clone() implementation.
I understand what you are saying but there is a perception problem with the audience.
Installing something versus simply browsing to page is avoided by a lot of people and business users in particular (security concerns). For example I currently contract for a paranoid client that has blocked write permissions to the C drive of my work computer, yet I can easily login to my bank via the web.
Looking at Rocky's comment further below, it seems that Silverlight may have severe limitations. I will start looking at a "smart" application that can be launched from a website but work like a disconnected application. The only concern I have there is that it is not cross browser compatible and you will end up restricting it to IE7 browsers with CLR installed at the client's end as well.
I will have to look a Silverlight in depth soon, but it may have to have some sort of a compromise where the mobile objects can be converted into XML via a web service. In any case, this will need further investigation into the compession mechanisms as CSLA.Net will be out of the picture (at least on the client end). Maybe use some clever javascript to compress/uncompress XML traffic??
Thanks for your ideas
Shailen Sukul
Software Architect/Developer
Ashlen Consulting Services
shailensukul:
Maybe use some clever javascript to compress/uncompress XML traffic??
I still think the simplest solution is to turn on HTTP compression in IIS. As I understand it, that'll compress all your web traffic, including the AJAX callbacks from Silverlight.
You are correct - Silverlight does have some serious limitations. It is a subset of .NET and of WPF, restricted by both size (for install reasons) and security (it is a strict sandbox). This is why I am researching the "CSLA Light" idea - because CSLA .NET contains features that rely on .NET functionality that simply won't be in Silverlight.
Copyright (c) Marimer LLC