SL3: Adobe AIR is dead!

“Out-of-browser Experiences have now come to Silverlight.  This is a highly requested feature and is enabled with no additional download/plugin.  Each and every Silverlight 3 application can be enabled to run as a desktop application (yes, cross-platform with Windows/Mac) by subscribing to a series of APIs and defining the application in the manifest. “

Silverlight 3 spoilers

 
Cool, in SL3, we’ll have the concept of screens and deeplinks out-of-the-box. Too bad we have implemented it @Axinom several times already (in different teams).
 
They’ve also added a mightly overview/detail controls – can it be interesting for AxCMS user interface?

Progressive download CPU consumption

As progressive download consumes more CPU than streaming, I’ve decided to research this issue further.
 
I’ve implemented a possibility to throttle the bandwidth used for the progressive download. The throttling happens on the client side, by inserting some Thread.Sleeps in the loop where the downstream is being repeatedly read in a memory buffer.
 
And I could measure the following CPU loads:
Progressive download
(unconstrained)
40%
Throttled to 6mbit/s
28%
Throttled to 2mbit/s
23%
Throttled to 1mbit/s
18%
Adaptive Streaming
10%
 
In the adaptive streaming case, I believe, it is not only their more optimized download loop implementation, but also the fact that they use MP4 container format instead of ASF can play a role. Alex Zambelli describes Smooth Streaming Architecture in his blog (Smooth Streaming is an alias of adaptive streaming).
 
I will also test CPU consumption for the same movie when it is being streamed via Windows Media Services, when I obtain a new test server.

Working off requirements

People are different. I have to think about this axiom every time I see a statement I can’t apply for myself.
 
One of such statements is a wish to get ideal software requirements and to work them off, preferrably left alone.
 
Every time I’ve tried this approach, a produced a dead-born something, that has corresponded pretty much to the requirements, but nobody wanted to use it.
 
I’m confident, it is not a coincidence. 
 
As a product owner, you know what a successful application must look like. You can communicate these requirements explicitely and verbally, or implicitely and non-verbally.
 
In the latter case, you have to make the developers to share your vision. When you succeed, they will evolve (even better and more complete) requirements on their own. In the former case, the communication channel is rather limited and too one-way-ish.
 
Without perfect knowledge, what exactly will make the app to success, developers will create just some set of bytes, albeit perfect in its internal architecture, but otherwise useless.
 
Making successful apps is more important to me than making apps with clear architecture.